Websense Security Labs Blog

Websense Security Labs discovers, investigates and reports on advanced Internet threats that traditional security
research methods miss.

Latest Blog Posts

View all posts > 

(April 2010) Posts

Analyzing Malwares Using Microsoft Tools

Posted: 29 Apr 2010 01:04 PM | Anonymous | no comments


We have been seeing reverse engineering on malware for a while. Some time ago you needed to have magic tools from some underground hackers, but the situation has changed a lot since then. This is especially true for reverse engineering on the Windows platform, where there are a lot of good Microsoft-made tools. They are not specifically made for reverse engineering purposes, but they can be very helpful for reverse engineering binaries. They are also very stable because they went through a lot of internal quality assurance processes before being released to the public. It feels like these Microsoft-made tools are underestimated. Many hackers are using ollydbg instead of Windbg. Many people are using some other dumping tools to dump processes instead of userdump. And so on. It's not that ollydbg or other tools aren't good. I just want to show how easily the same thing can be achieved with the tools released by Microsoft. I'll show two things: dumping processes, and finding rootkit components embedded in the process images. Both of these can be achieved with just a few lines of commands. The situation is as follows. We have a machine infected with a malware, a kind of a Zbot variant. We know the malware is doing code injections to collect and control the data flow on the system. So we decide to dump the process image. How can this be achieved with Microsoft tools? We just need to download and install User Mode Process Dumper Version 8.1 on the target system. Here's an example showing the dump of the infected "svchost.exe" process image from the system. Illustration 1: Using userdump to dump live process images You just need to call userdump.exe with the target process name and target dump file name. It will go through every process with that specific name and dump the image to a file with the name you designated plus the process ID. In one shot, you can grab all the dump files for each process with same name. Convenient, right? One more benefit of userdump is that it will not kill the process it dumped. So theoretically, the process will not be affected by dumping the images. We can silently duplicate the process images and let the system carry on without intervention. So now we have the corpse images of the processes and it's time to do some basic autopsy work to see which organs have been tweaked by this infectious botnet client. First, you need a tool called Debugging Tools for Windows (aka Windbg). There are, however, some issues with the Windbg download. The last release date for the standalone download package is March 2009, which is more than a year ago. You need to download and install WDK to use the latest Windbg. But in my case, I was just fine with the March 2009 release. And the examples here will work without any problems with standalone packages. Just move all the dmp files acquired from userdump to a safe location. Launch Windbg and select File > Open Crash Dump . Then choose the dump file you want to analyze. If you come from the ollydbg world, the first thing you'll notice is the UI. It doesn't have a fancy GUI like ollydbg. You need to know the debugging commands to achieve anything, even simple things. This can be a big hurdle for the people who are accustomed to full-blown GUI debuggers. But there are still many advantages to this command line approach. You can copy and paste the commands easily. And you can save all the data in a text file for further review. Everything you do inside the debugger is logged, and you can keep those logs as your record. Also Windbg supports a kind of a semi-scripting like the "Debugger Command Program", which makes your life easier if you are performing simple tedious repeating tasks. We will use this small portion of the Windbg script feature to find the hooks installed on the target process. The following one-line command will reveal every hook (especially if they are inline hooks): !for_each_module !chkimg @#ModuleName -d !for_each_module is a kind of extension command. Every command that starts with "!" is an extension. It executes the following command for every module on the target process. The command to execute for each module is "!chkimg @#ModuleName -d". !chkimg is a command that compares the image on the memory and symbol file or executable file. @#ModuleName will be replaced with the module name that is being executed. The command "!chkimg" will compare the image with the one in the symbol store. In this case, we should use the symbol store from Microsoft. If you don't have your symbol path configured, execute the following command from inside the Windbg command prompt: .sympath+ SRV*C:\localsymbols*http://msdl.microsoft.com/download/symbols "C:\localsymbols" can be replaced with any local directory that you want to use for symbol cache files. Here's the result of that "!for_each_module" command with the "!chkimg" command. Basically, it will iterate through all the modules loaded in the process and check the executable image against the one stored in the Microsoft symbol store. If anything has been modified, it will report the discrepancies. Illustration 2: The section inside the red square shows the APIs where the malicious hook is installed From the above picture, you can see that a lot of APIs from ws2_32.dll (winsock) and wininet.dll have been modified. You can quickly see that this malware is monitoring and modifying the network traffic by hooking network-related APIs. For example, let's look into WSASend API from the ws2_32.dll file. You can use the "u" command to disassemble any portion of the memory. Here, we disassemble the "WSASend" API. The first instruction of the API is a jmp instruction to the memory location 0x00b7dbbd. Illustration 3: ws2_32!WSASend inline hook installed We disassemble that part of the memory using the "u"(disassemble) command. You can see that...

Read more > 

Filed under: , ,

New blog!!

Posted: 25 Apr 2010 11:00 PM | Patrik Runald | no comments


As you can see we have a new blog. In addition to the new look-and-feel we have a few new things in place. - We have merged the blog and alerts. If you subscribe to our Alerts you will still get emails when we see something that warrants an alert - Added Categories to posts. This will make it much easier to find stories around the same topic We will add the ability to post Comments to the blog as well in the near future. We hope you'll like it. Remember to update your RSS feeder address by clicking on "Subscribe" in the top-right corner as the old RSS feed will not be updated.

Read more > 

Spammers also "Recycle"

Posted: 25 Apr 2010 09:09 PM | Anonymous | no comments


Imagine how much trash or rubbish is being recycled on a daily basis in real life. The same thing is happening on the Internet. Spammers create new Web sites, then they use all sorts of techniques to deliver those sites to end users. However, in most cases there is a Web/email filtering service like that offered by Websense, which will analyze and block such sites. At some point such URLs would be blocked by all known companies providing filtering services, and the URLs would become useless for cybercriminals. The whole process starts again from the beginning: the spammer creates a new page, advertises it and finally it's blocked by a Web/email filtering company! Unfortunately spammers have started to come up with new solutions, something we're calling "Recycled" Spam URLs. "Recycled" Spam URLs could be created from major services, such as caching or translation, provided by major search engines. Recently in Websense Labs we've seen several spam emails with "Recycled" spam links. Some of those emails contain just a link. Others look like legitimate newsletters. Unfortunately ImageShack removed the picture. If they follow the link, the user is redirected to a cached version of the site which either had another redirect, or was compromised and had a malicious iframe or code embedded into a source. As shown in this example pages could stay cached for about 2 months or even longer. And finally the landing page - it's just another Pharma spam! To make it even more difficult for Web/email filtering engines to detect such links, cybercriminals also are trying to obfuscate links with URL encoding, and in most cases criminals use infrequently-seen Google top level domains belonging to countries such as Anguilla, Gibraltar, American Samoa or the Seychelles. hxxp://google.com.ai/search?q=cache:www. [removed] %63%65%6E%74%65%72%2D%6D%73%6B%2E%63%6F%6D#online hxxp://www.google.com.gi/search?q=cache:%6C [removed] %6E%74%65%72%2D%6D%73%6B%2E%63%6F%6D#Zubkepzb2j.html hxxp://www.google.sc/search?q=cache:%6C%61%77 [removed] %6E%74%65%72%2D%6D%73%6B%2E%63%6F%6D#Stoettxgr4j This is also very similar to the BlackHat SEO. If the site has a good ranking, cybercriminals change the content for the one to be cached, then ping the crawlers (<searchengine_URL>/ping?sitemap=sitemap_url) and after a while remove the content or block the site. The cached version has exactly what they wanted and they start their campaigns. As the site does not exist anymore, search crawlers can't pick up the newer version and the cache keeps the last version of the parsed page "forever". The same technique is used for compromised sites with good rank: once the site is abused, cybercriminals wait for the site to be cached, then they remove malicious content and use it in campaigns. The only problem the bad guys face is that high-ranking sites are being parsed with search crawlers very frequently, and the cached version which hosts bad content has a short period of live time. Websense customers are protected, as the Live Analytics are blocking such pages in real time. Security Researchers: Artem Gololobov, Ivan Sabo

Read more > 

Filed under:

Oversharing and a powerful search engine = FAIL

Posted: 23 Apr 2010 10:56 AM | Patrik Runald | no comments


Users of the Blippy service, a website that lets people share their credit card purchases online, are scrambling to change their settings or even closing their accounts after VentureBeat published a story about how Google searches can disclose users credit card details. As can be seen in the screenshot above Blippy shows every purchase made with linked credit cards, bank accounts, Amazon, iTunes account and more. In today's world of social media and an eagerness to share your with friends (and sometimes the world), Blippy fits right in. And Blippy claim to take privacy seriously as can be seen from the following statement from their website. However, things don't always work as planned. Google has indexed the private information and it's now publicly visible in search results as can be seen below. This is a cyber criminal's dream come true. We advise every user to be really careful when you share your sensitive financial information with anyone and consider the worst case scenario about what could happen. Blippy and Google are working on correcting the problem and we'll update the blog when we know more. Update: Blippy has posted a response here . Update 2: Google's search results have been cleaned up and the information is no longer available.

Read more > 

Filed under:

De-obfuscating the obfuscated binaries with visualization

Posted: 19 Apr 2010 07:42 AM | WebsenseSecurityLabs | no comments


Recently I spent an afternoon reverse-engineering a few packed and obfuscated malware binaries. I was curious as to what kind of tactics and methods had been applied, so I dissected several binaries. I want to share some of my notes about the techniques that these malware programs used. I also want to share some of my analytic techniques and a few of the scripts that I used to help me with the analysis. Most of the obfuscation techniques were in the realm of polymorphism that has been known for years, even decades. I want to show you how a few scripting and graphing tools can ease the burden of de-obfuscating and understanding these malware binaries. Fake Exports Yes, fake exports. In this case, an executable was exporting multiple entries, which is unusual. The program exports some random points of the binary with random names, and IDA (Interactive DisAssembler) is so sure that it is a separate function that it breaks up the control flow. Illustration 1: A function split by exported entry It's very hard to remove a function when it's exported. The exported functions tend to have random names. So I wrote a IDAPython script that searches for functions with names that are not auto-generated by IDA, and removes them. It searches for any function that doesn't have name "start" or default name prefix "sub_". [Update: I got a comment that you can also use GetEntryPointQty()/GetEntryXXX() IDA API to achieve this in more stable fashion] Visual Interference with NOP repetitions As I continued through the disassembly, I found that it had a repeating pattern that had no meaning at all. The pattern just pushed a register, modified the same register, and pop it off again. The register did not change at all. This is just a NOP pattern. And it was inserted all over the place, making the analysis very tiresome. The NOP pattern looked like the following. Illustration 2: Repeating NOPs Actually, the "db 3eh" byte is not valid according to IDA[Update: Many folks pointed out that db 3eh doesn't mean that it's invalid, but meaningless which is more correct word], but the processor didn't care. So, all of the red-boxed regions are simply meaningless overhead put there to make the code more overwhelming. To make analysis easier, I simply replaced all such instances with real NOPs. And I felt a lot better after I did. Here's the script that I used. It searches for the "50 3e 0f c8 58" byte pattern, which is the hex representation of the NOP parts, and patches in real NOPs(0x90...). Here's what I got after the script execution. Illustration 3: NOPs converted to real NOPs Basic Block Chunks The malware had a lot of chunked code, which malware often includes in abundance because it is widely known that IDA doesn't deal with it well. Here's an example of the chunked code. It's heavily split through the binary using jmp instructions. Illustration 4: Chunked code using jmps When you look at it in the graph view, it's almost impossible to decipher. IDA failed to create a useful graph. Illustration 5: IDA is especially poor in dealing with code chunks. So I wrote a script called IDAGrapher to do the analysis correctly even with chunked basic blocks. And here's the graph that the tool generated. [Update: A person pointed out that you can fix the xrefs to show correct graphs, but in my case it didn't work for some reason and my grapher doesn't have any additional algorithm to draw the graphs correctly, so I suppose the IDA graph functionality is not perfect or sometimes not adequate for use] Illustration 6: So it looks much better It uses power of graphviz ( http://www.graphviz.org/ ) graph tool to generate the graph file. Packing I started with malware that was packed and the unpacking routine was obfuscated and I de-obfuscated the unpacking routines. Next I wanted to find out where the original routine starts. Here's a portion of the whole graph. The whole graph is huge; however, I just needed to concentrate on the green blocks. The green blocks are terminal blocks. Terminal blocks can return or jmp to a register assigned location or a stack assigned location. So I may not be able to determine the next control flow easily, but I should be able to determine it dynamically. This means that it's a strong candidate for the OEP jumping point. Here's the zoomed-in shot. Illustration 8: The block that returns to original routines We can see that it's returning, but sometimes malware just pushes a jump address onto the stack and uses "ret*" instructions to achieve code jumps. So I placed a break on the specific instruction and executed the binary using the IDA debugger. Here's what I got: Illustration 9: The point before the jump to original routines After that, if we "step over" the instruction by pressing F8 key, we get this. So "sub_416616" might be the first function called inside the packed binary. To make it sure, look into the original packed binary, the same location looked like following. So I can be sure that the binary is unpacked now. Tracing through the program step-by-step without any idea of the control flow is very tedious and time consuming. The graphical view generated by the simple script helped me know where to put a breakpoint to catch the OEP. In this case, I just had to look into the green blocks. The source code for this IDA graphing tool is a little bit big, so I put that on the googlecode site. You can grab the code here ( http://code.google.com/p/idagrapher/ ). The code is far from complete. It's really just a proof of concept. You can modify the code for your own situation. Security Researchers: Matt Oh

Read more > 

Filed under: ,

Multi-layer Obfuscated JavaScript Using Twitter API

Posted: 16 Apr 2010 07:26 AM | Tamas Rudnai | no comments


Nowadays infected Web pages are probably the biggest threat to the IT sector. Most compromised HTML documents contain a JavaScript that generates the malicious content dynamically to make it less obvious what it is doing. To avoid detection, they are using more and more complex obfuscation techniques. In this blog we will analyze a sample with 5 different obfuscation layers using a few tricks to fool automated de-obfuscation engines. Our sample today is a 6KB obfuscated JavaScript that by the end turns into a single iframe pointing to a malicious site. The threat is using a mixture of Codebook , XOR and substitution ciphering as well as the traditional character representation tricks to hide the malicious content. Some of these techniques have already been discussed in this blog . To decrypt it, we need to tweak the code a little bit so that the evil script reveals its true nature - as opposed to silently executing the payload. As you can see the injected code looks strange, but other than that it does not tell us whether the code is malicious or not: What you can see from here is not that much, except you can be sure that the script is obfuscated. For a security expert this kind of code is always highly suspicious as it reveals that the author of the code wanted to hide something for a good reason. If you are indenting the code properly, however, it shows something more to the human eye. Actually you can then divide the code into two parts. In the first part there is only a very short function and a definition of a variable: Note that we cut off the value of the variable as it was just too long and is not needed to understand this algorithm. The second part is another function and a call to the first function mentioned above: As you can see it calls function t() which is only a wrapper around function z(), most probably only to use it as a light anti-de-obfuscation technique. Therefore we need to analyze only the second function. It is very easy to spot that it uses simple substitution ciphering, this time only for the letter 'Z'. Also it uses char representation coding, where for decoding it only uses the unescape() function. At the end of the script, you can see the eval() function call. This one needs to be replaced with a print() instead in order to display the de-obfuscated code: These are the results, and they are something different from the first layer; however, it all still looks quite cryptic. Many of the malicious JavaScripts today are using multi-level obfuscations. As described in an earlier blog we have to decrypt such code layer by layer. In each layer we can see new details of the code: some of them are valuable during the analysis, some of them are not. Have you noticed the clear URLs at the bottom? There is definitely something there to investigate. Again, we can use indentation tools (or to use their more fashionable name, code beautifiers) to see what is behind the scenes: We can see the Twitter links, which are clean of course. We could easily come to the wrong conclusion that the script contains only clean URLs, and is therefore not malicious. However, as the bigger part of the script is still cryptic we have to suspect that there is much more behind the scenes. To understand why these clean links are there, we should study the Twitter API set a little. In this blog we are not diving too deep into this subject. It's enough to know for now that we can include JavaScript APIs from Twitter in order to gather information dynamically from the popular microblog site. With some of these APIs we can then pass the name of a callback function which will then be called from the API. This is a great trick against even the more sophisticated de-obfuscation engines, and also for all black-boxing machines not connected to the Internet - no Internet, no Twitter, therefore no callback. The sample on our plate uses the 'trends.daily' API which returns the daily trending topics in Twitter. We can easily see the 'callback=' parameter, which tells us the name of the callback function. Later on, that function will be called automatically with the list of trend topics as a parameter. Also we can see that the format of this list is in JSON, which can be processed very easily by JavaScript. If we look at that code snippet even more closely, we can see that it uses two of these callbacks. The first one is only to determine the date. It also fires up the second callback function, which then utilizes the eval() function in the middle. Note also the following document.write() function, which we will discuss later. In order to be able to decipher this layer, we need to get to the stage where that eval() function is called with the proper parameters. For this we either need to completely emulate the browser environment including Twitter APIs, or need to modify the code a little bit to get over those callback tricks. For the sake of simplicity I just commented out the part of the code that is not needed just now, leaving only the eval() function call (replacing that with a print() of course). Let's see what we have: At this stage we are a bit closer to the finish, but the fun part just starts here. This bit uses global variables previously defined in the upper layers, so we need those. Once we copy over the variable set, we realize that the function named 'cz' interferes with the variable of the same name. If we quickly look back, we can see that the eval() function that generates this code snippet is embedded into the callback2() function. This means it is in a function context, not global. That's why it is no problem for the script to override the original definition of the 'cz' and redefine it as a function. This trick, however, makes harder to emulate the code. In addition to this, it plays with the variable names inside the dw() function to fool simple de-obfuscation engines, which are using context-free grammar only. Furthermore it keeps reusing...

Read more > 

Filed under: ,

New Zbot campaign comes in a PDF

Posted: 15 Apr 2010 11:45 AM | Patrik Runald | no comments


Websense Security Labs™ has received several reports of a Zbot trojan campaign spreading via email. We have seen over 2200 messages so far. Zbot (also known as Zeus) is an information stealing trojan (infostealer) collecting confidential data from each infected computer. The main vector for spreading Zbot is a spam campaign where recipients are tricked into opening infected attachments on their computer. This new variant uses a malicious PDF file which contains the threat as an embedded file. When recipients open the PDF, it asks to save a PDF file called Royal_Mail_Delivery_Notice.pdf. The user falsely assumes that the file is just a PDF, and therefore safe to store on the local computer. The file, however, is really a Windows executable. The malicious PDF launches the dropped file, taking control of the computer. At time of writing this file has a 20% anti-virus detection rate (SHA1 : f1ff07104b7c6a08e06bededd57789e776098b1f). The threat creates a subdirectory under %SYSTEM32% with the name "lowsec" and drops the "local.ds" and "user.ds" files. These are configuration files for the threat. It also copies itself into %SYSTEM32% as "sdra64.exe" and modifies the registry entry "%SOFTWARE%\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit" to launch itself during system startup. When it runs, it injects malicious code into the Winlogon.exe instance in memory. This Zbot variant connects to malicious remote sever in China using an IP address of 59.44.[removed].[removed]:6010. Screen shot of the email message: Saves the malicious embedded file Adobe Acrobat Reader shows a warning about launching the file: The problem lies deep inside the PDF file format. This technique is similar, but not the same, as explained in this blog post . Websense Messaging and Websense Web Security customers are protected against this attack.

Read more > 

Filed under:

This Month in the Threat Webscape - March 2010

Posted: 12 Apr 2010 02:37 PM | Jay Liew | no comments


We presented at RSA 2010 and spoke at the Cloud Security Alliance Summit . Here is our recap of the event . Major hits 1. Highlight pwns from CanSecWest's Pwn2Own hacker 2010 contest include: 2. Contest winner (Peter Vreugdenhil): IE 8 vulnerability exploited on a fully patched Windows 7 machine. 3. A malicious Web site that, when visited from a fully patched iPhone , steals the phone's SMS (text messages), including deleted texts, and uploads them to a server of the attacker's choosing 4. A malicious Web site that, when visited from Safari on a MacBook , allows the attacker full control of the Macbook. This is Charlie Miller's hat trick. 5. Mozilla Firefox had a vulnerability exploited with a drive-by download . ASLR and DEP on Windows 7 were bypassed. In other news, the Sougou BBS Web site was compromised and injected with a malicious iframe. Searching for Corey Haim on Google led to malicious rogue AV Web sites , as did searching for other blackhat SEO poisoned terms like March Madness , and various sensational topics and events . Web 2 dot uh oh Last month, we detected that over a quarter million malicious links were posted on various Facebook pages , including those belonging to celebrities like Justin Timberlake. In the blog post, we include a video showing just how quickly the links are spreading. (Note: be careful what you click on!) Websense Security Labs has also been monitoring the latest WordPress attack that saw over 250,000 injections over a span of just 2 weeks . Browser and friends Is the fully-patched browser safe? Look at the Vancouver Pwn20wn 2010 contest. Fully-patched IE8, Safari, and Firefox have been hacked. The good news is that the zero-day vulnerabilities the hacker used are not spreading in the wild. This will help the browser vendors to complete their products. Apple released security update 4.0.5 for Safari , patching 16 vulnerabilities. Mozilla has also done a lot of work this month, releasing Firefox 3.6.2 , which fixed 15 vulnerabilities. Opera released 10.51 for windows with two vulnerabilities patched. According to F-Secure's research , PDF-based targeted attacks have been increasing in the past few years, reaching 61.2% in 2010. A good example of this type of attack is a campaign related to FIFA World Cup 2010 theme that has spread in the wild in March. Victims receive an email containing a PDF that exploits CVE-2010-0188 , though the vulnerability was back in February. Microsoft March brought two new Internet Explorer zero-days, one requiring an emergency out-of-band patch and one still unpatched. The first is a vulnerability in Internet Explorer ( CVE-2010-0483 ) that gives attackers remote code execution capabilities on the machines of IE users who are tricked into pressing the F1 key for help. The attack involves specially-crafted VBScript and Windows Help Files for IE. While POC code has been released detailing the exploit, no attacks have yet been seen in the wild. Microsoft plans to release a patch for this bug in April. While the F1 zero-day vulnerability wasn't addressed, March's Patch Tuesday did include 2 important remote code execution bulletins . MS10-016 addresses versions of Windows Movie Maker that ship with Windows XP and Windows Vista, and involve users opening malicious Movie Maker files. The second bulletin MS10-017 patches all currently supported versions of Microsoft Excel, both on Windows and Mac to protect against attackers convincing users to open a malicious Excel document to exploit their machines. The biggest Internet Explorer news this month was a zero-day vulnerability ( CVE-2010-0806 ) involving a use-after-free bug in the Peer Objects component (iepeers.dll) in IE6 and IE7. Microsoft released an advisory providing mitigation options, emphasizing that IE5 and IE8 are unaffected, and stating that they had seen limited targeted attacks in the wild. An Israeli researcher released working exploit code for the vulnerability, and integrated it into the Metasploit Framework . Microsoft released a quick-fix that disabled the offending component, but was forced to release an out-of-band patch for the actively-exploited vulnerability on March 30. You can find more details about this vulnerability in our detailed analysis of the exploit code found in the wild . Hello ThreatSeeker, you've got mail! This past month has seen some diversification of social engineering in malicious spam. Spammers have abused big brand names to entice possible victims into clicking on URLs in messages. One such example we alerted on was an Apple App Store campaign. With this campaign, spammers abused the good reputation of legitimate sites to host their redirects. Compromised sites were linked in Apple App Store spam and would redirect to the final spam site destination. In some cases there were even client side exploits hosted on the redirect sites! Spammers also tried to lure victims by sending fake Skype toolbars for Outlook. A couple of new and interesting spam cases included two countries and a big sporting event. Spammers used scare tactics as a lure for victims to open malicious ZIP attachments. The emails were spoofed to look as though they were sent from official US intelligence agencies and stated that North Korea had launched a missile at Japan. Riding on the PDF infection train, spammers also sent out targeted attacks containing infectious PDF files. The attacks consisted of FIFA World Cup themed messages with a PDF attachment. These attachments were laced with exploits intended to compromise the end user's computer. Security trends BeyondTrust collected data from Microsoft Security Bulletins published throughout 2009 and released a report pointing out that 64% of all the reported Microsoft vulnerabilities for 2009 could have been mitigated by using the principle of the least privileged accounts. By staying well under the radar (unlike obvious and annoying adware) malware writers can now build a residual income...

Read more > 

Filed under:

Celebrity life of Black Hat SEO

Posted: 08 Apr 2010 10:22 PM | Patrik Runald | no comments


It’s not a secret that cybercriminals use all sorts of techniques to promote their fake products and services on the Web. To increase the rating of the newly-created fake medical or rogue AV Web site, criminals sharpen their skills in Black Hat SEO (search engine optimization). While White Hat SEO is basically being used by all businesses as well as other non-profit sites, Black Hat SEO poisoning is mostly used for sites that do not want to build their traffic and popularity in a natural way. In some ways Black Hat SEO is a kind of celebrity life – popularity can be on the rise in a couple of weeks or even days and then abandoned just as quickly. In both cases, this short popularity span can bring enough attention or revenue so that it's not in vain. Search engines like Google, Yahoo, or Yandex invent new solutions every day to filter sites using Black Hat techniques and not allow them to achieve their aim – which is to be seen on the first pages of search engine results when people are looking for genuine information. If such sites manage to reach top search result positions, the traffic generated by people visiting the Web site will rapidly increase. It is worthwhile for Black Hat SEO teams, even with the risks of being shut down, because of the immediate visibility that their site gets - their 15 minutes of fame. This is another similarity to a celebrity's life: to be banned only once means they will never be highly rated again. The popularity can be built fast, and destroyed even faster. There are many common techniques used in Black Hat SEO which lead to more or less the same target. It all depends on the time available, the ability to take a risk, and of course, money. Backlinks – the most common and popular technique. It is not important how many links you point at, but how many links point to you. It's even better if the links are bidirectional, which is of course more difficult to achieve. Therefore "link farms" became a popular service not long ago, offering many servers pointing to one specific site or pointing to each other to build inter-linking. This approach has quickly been discovered and cracked down on pretty well by companies like Google, Yahoo, and others. So Black Hat guys started to infect pages through mass injections or other malicious means to get such links working in invisible form (hidden links) or in a pretty visible way, automatically populating forums, blogs, and directories. Of course, not every link has the same weight. There is a difference if a description of a link says "Go here" and points to "Quality meds", compared to a precise description. Also, links coming from high-ranked sites are weighted much more. Using a high-ranked domain (for example, YouTube) to propagate such products and services. Especially, accounts that have existed for a long time are much more likely to get better visibility. Image Crafting – every search engine advances some kind of a picture property. There are different approaches depending on the size, location, "href" description, and "alt" description of a picture. Using the right properties makes some pictures more easily visible than others. Cloaking – content presented to search engine crawlers is different than content presented to a user’s browser. This kind of "hiding" offers special protection against being noticed and banned. " Bait and Switch " – this technique is used to get high ranking usually using white methods, and subsequently switching the content from legitimate to something completely different. Even though nowadays this method is almost useless as search engines are parsing Web sites on a daily basis and notice switching immediately, sometimes a couple of hours is more than enough for criminals to achieve their aims. Microblogging is becoming more popular every day. Pages offering microblogs are getting high ranking very quickly and this ranking is automatically passed to all blog posts. One of many techniques abusing such sites is registering an account into many highly popular groups and slowly posting messages with “appropriate” words, or even better URL links to all of them. These messages get attention at once when posted, due to the fast and privileged indexing of such sites by search engines. Hence all of these crafted microblogs influence query results in a couple of hours. 301/302 redirect (also known as Get Your Traffic Now). Recently we posted an alert about Bloombox SEO poisoning – we have started to see more and more abuse of this technique. Let's have a look. Screenshot 1 – Bloombox Black Hat SEO Usually the abuse is achieved through a PHP file installed on a compromised host. The file keeps a parameter of the search term, in this case "bloombox". The search term is usually a word or a phrase used by customers to find information about a particular event. When they follow the link, the user is being redirected to a Web site with rogue AV. Screenshot 2 – Rogue AV trap presented as a “Bloombox” destination When trying to access the same link not from a Google search page but by directly pasting the URL into a browser, the user is redirected to http://www.cnn.com. Screenshot 3 – Imitation of direct input of URL into a browser The same thing happens when using a Google Bot referrer, pretending to be a Google crawler. Screenshot 4 – Imitation of Google Bot parsing the page The next step shows the case when the user gets access to the page from a Google search page. Screenshot 5 – Imitation of accessing the page from Google search. This site can be accessed only from a Google search page and only by a user. The whole trick is being done by a PHP file uploaded to a compromised host carrying the 302 (Temporary redirect) or 301 (Permanent redirect) with the cloaking mechanism. The redirection to an appropriate...

Read more > 

Filed under: , ,