Category Archives: General Thoughts

General thoughts about vulnerabilities and security

A Closer Look at the Twitter-Controlled Botnet

Photo: Don Solo

Photo: Don Solo

Today, I have asked Paul Makowski, a fellow security researcher, to write up a detailed post regarding the recently discovered botnet being controlled through Twitter. What I love about this article is how in depth Paul actually dug regarding this botnet – He actually had to break up the post into two separate posts.

This is only part one. In part one, Pual explains how he gets the malware, decodes, and scans it. In part two, Paul will delve into dissecting the malware and making sense of what it does.

Update: The mirrored malware links have been removed.

A Closer Look at the Twitter-Controlled Botnet (Part 1)


I wasn’t aware of Jose Nazario’s post concerning this topic while I was conducting this research; I had only been exposed to the Wired Threat Level article prior to researching. So while I present some of the same information as Jose, this duplication of information only came to my attention afterwords.

If you’ve read Jose’s post, this post may still be worth the read for several reasons:

  • Jose and I differed on some of the tools & techniques used.
  • I attempt to offer a more detailed description of my methods/logic as a pseudo-tutorial.
  • I mirror all the necessary info so the readers can do this themselves.
  • There’s a quick discussion on some malware I found hosted at (Jose probably saw it too but didn’t mention it) as well as a possible lead to a very sloppy botnet master.

Getting the Malware:

I was reading some feeds on Friday (Aug 14th) and came across Wired’s article on outsourcing botnet C&C (command & control) to Twitter. What caught my eye wasn’t so much the article itself but the screenshot accompanying the article. Many times when major outlets report on botnet/worms/virii/etc, crucial details are left out either intentionally (to protect the innocent) or accidentally. This was not the case with this article.

Paul Makowski

Paul Makowski

I immediately recognized the tweets in the above screenshot as being base64 encoded. Furthermore, all of the posts started with the same 18 characters, indicating to me that these are not encrypted nor obfuscated beyond the simple base64 encoding. Perhaps the botnet herders are using Robin Wood’s KreiosC2 for nefarious purposes? This is evidence for a fairly unsophisticated botnet herder.

I transcribed the messages captured in the screenshot and decoded them in order from most recent to least recent. Some contained what appeared to be multiple links (redirections valid as of Aug 14th, 2009):

aHR0cDovL2JpdC5seS8xN2EzdFMg (malware)


aHR0cDovL2JpdC5seS9MT2ZSTyBodHRwOi8vYml0Lmx5L0ltZ2 (malware)

|_ (unrelated?)


aHR0cDovL2JpdC5seS8xN2w0RmEgaHR0cDovL2JpdC5seS8xN (malware)

|_ (unrelated?)


aHR0cDovL2JpdC5seS9wbVN1YyBodHRwOi8vYml0Lmx5LzE3b (malware)

|_ (unrelated?)


aHR0cDovL2JpdC5seS9HaHVVdSBodHRwOi8vYml0Lmx5L1FqC (malware)

|_ (unrelated?)


aHR0cDovL2JpdC5seS9RakFaWQ== (dead link)


aHR0cDovL2JpdC5seS83UGFEOQ== (dead link)


aHR0cDovL2JpdC5seS8zUndBTiBodHRwOi8vYml0Lmx5LzJwU0 (dead link)

|_ (unrelated?)


There’s several interesting items here, in no particular order:

  1. It appears as though Debian is better at proactively moderating these type of posts than Ubuntu is (all the Debian links were dead when I tried them but the Ubuntu link worked fine). In Ubuntu’s defense, however, the offending links were killed within an hour of me notifying them.
  2. Payloads are being pushed out in rapid succession to both the C&C venues (Twitter, Jaiku, Tumblr, etc) and the payload hosting sites, indicating that this process has been automated. Automated payload deployment was determined by looking at some of the URLs linked in the Twitter screenshot:

    It can be deduced from these URLs that malware was uploaded to in a short enough time period to warrant consecutive numbers. Furthermore, it is clear that whoever controlled the Twitter C&C made these uploads as well, judging by the upd4t3 handle present across services.

  3. All the Twitter posts that included two redirect URLs appear to have a nonsense link as the second URL. If anyone has a theory as to the purpose of these secondary links, please leave a comment or shoot me an email @ my[remove_this]
  4. The botnet herder’s name is Rafael? I took another look at the malware hosted at Ubuntu and removing the plain/:
  5. (mirror)

Decoding the Malware:

Get the base64 samples. [Link Redacted]

Turning these base64 strings into something meaningful was more involved than simply decoding them. Still, the first step was to decode them. For that I wrote a little Python script. (I’m new to Python and figured this would be a simple exercise. It was.)

# decodes base64 files

# (C) 2009 Paul Makowski. GPLv2.

# usage: python / (encoded_file) (output_file)

import base64

import sys

encodedFile = sys.argv[1]

outputFile = sys.argv[2]

encodedFileHndl = open(encodedFile,”r”)

outputFileHndl = open(outputFile, “w”)




After decoding the malware I now had 5 files and named them after their URLs: 9506, 9507, 9508, 9509 & 252515.

I ran an md5 on all of them (I used OS X… it would be md5sum in Linux):

$ md5 *.base64

MD5 (252515.base64) = a5f84f74cf9aa832355d5cd558cbfca6

MD5 (9506.base64) = 7743eac81be2b803093a6277323f17cb

MD5 (9507.base64) = a5f84f74cf9aa832355d5cd558cbfca6

MD5 (9508.base64) = a5051a6e5365bdc4dd8267e62d3e2902

MD5 (9509.base64) = 1a81e69e65b75f8b9e72e94c6f86a52b

As you can see, payloads 9507 from and 252515 from are actually the same payload. (Yes I know about md5 collisions…but there’s very little point to messing with the hashes in this scenario.)

So now we’ve narrowed down the available payloads to 4: 9506 through 9509. I named these 9506.bin through 9509.bin (since at this point I didn’t know their true filetype).

Making Sense of the Malware:

The first thing I tried after I de-base64′ed the payloads was to take a look at them with a hex editor. Being on OS X, I used Hex Fiend (if I were on Windows, I’d use WinHex; Linux I’d use hexedit):

Hex Fiend

Hex Fiend

I took note of two items:

  1. This is not a Windows executable; this is a .zip file. I determined this by the magic number at the beginning of the file (seen above). PK means zip; MZ (or ZM) means Windows PE.file verified these findings:

    $ file 950*.bin

    9506.bin: Zip archive data, at least v2.0 to extract

    9507_252515.bin: Zip archive data, at least v2.0 to extract

    9508.bin: Zip archive data, at least v2.0 to extract

    9509.bin: Zip archive data, at least v2.0 to extract

  2. There’s a file called gbpm.dll inside the archive. At the bottom of the binary (not shown), is another string that reads gbpm.exe. This also turned out to be a file in the archive.

All of the other payloads appeared the same way under a hex editor. I renamed them all from *.bin to *.zip and unzipped them.

Now I had four folders, each containing a unique gdpm.dll and gdpm.exe. I renamed all the gdpm.exes to gdpm.livemalware so I wouldn’t accidentally execute them on my Windows box.

I checked the md5s to see if any were duplicates:

$ md5 950*/*.dll && md5 950*/*.livemalware

MD5 (9506/gbpm.dll) = 0dc041988367e4ca0faa1f119c748efb

MD5 (9507_252515/gbpm.dll) = 6cd9ee23dedf7c6a53668a7c4f830d78

MD5 (9508/gbpm.dll) = 1a1b3c05470ea788a86c4b9ed5c9b28f

MD5 (9509/gbpm.dll) = b15df1614d09ebb7b15d04ce914ee05f

MD5 (9506/gbpm.livemalware) = 4c537d461490ac998256c6deca11eeb4

MD5 (9507_252515/gbpm.livemalware) = 359ca7a025c3fe3cb7f60a3dd8ff4478

MD5 (9508/gbpm.livemalware) = b3a7f3145dc93e8721a4078f5e32fb44

MD5 (9509/gbpm.livemalware) = 08b05a33c6a989cc9c3f0a0918afa943

None were the same – I have 4 different pairs of malware samples 🙂

I uploaded the files to Virustotal to see if any were recognized. AV detection was poor to say the least (not that I’m surprised):

9506/gbpm.dll (4/41 antivirus detection) (new file)

9506/gbpm.exe (11/39 antivirus detection) (new file)

9507_252515/gbpm.dll (4/41 antivirus detection) (new file)

9507_252515/gbpm.exe (13/39 antivirus detection)

9508/gbpm.dll (5/41 antivirus detection)

9508/gbpm.exe (13/39 antivirus detection)

9509/gbpm.dll (6/41 antivirus detection)

9509/gbpm.exe (8/41 antivirus detection)

The files marked new file had not been seen by Virustotal previously. All .dlls had a fairly low detection rate. That combined with the fact that some had not been seen by Virustotal previously reminds me of PandaLabs recent press release on virii only being useful for 24 hours.

So what kind of malware do we have anyways? Virustotal points toward Eldorado or Svelta for some files. Jose says in his post that these aren’t the botnet control agents, but are additional feature-adding payloads. Perhaps this means keyloggers, DDoS tools, etc?

Note: The domains found hosting malware have been notified (Ubuntu, The malware has been taken down from these sites in order to prevent further propagation, but is offered below in a password protected archive for the reader to practice on.

Don’t Click That Link!

Photo: B.G. Lewandowski

Photo: B.G. Lewandowski

Why did you just click that link? Most likely you have came to this site by clicking a link from another site. Why did you do that? Did you trust the person who sent you the link? Did you click a link from Twitter, Facebook, or an email someone sent you?

When you click a link, you are telling your browser, “I trust this person.” However, this is not the way we use the Internet. We click on links all the time. We click on links from “untrusted” sources. We click links from people we don’t know and we even click on URL’s that have been modified. On Twitter, a person is much more inclined to click the shortened link then they are to click Even though the shortened link could redirect to the site.

But, why would someone trick you into clicking a cleverly disguised link? The site that you are redirected to may seem harmless. It could also be extremely malicious.

What happens if this page, (the one you are currently viewing), was filled with Cross-Site Request Forgery (CSRF) links? This web page could be setup with all types of malicious intent. However, you didn’t know that when clicking the link. Now, it is too late.

If this site did have Cross-Site Requests, I could do things such as:

  • Change the password on your Facebook account
  • Transfer the money from your on-line bank account to another account
  • Enact trades from a financial institution such as E*Trade

The sites that I exploit would have to be vulnerable to CSRF. But researchers, such as Mike Bailey and Russ McRee, are constantly finding CSRF vulnerabilities in web applications.

An example of how clicking links from untrusted sources is never good was demonstrated in Billy Rios and Nitesh Dhanjani, Bad Sushi talk. In their presentation they described sending phishers a word document stating their account numbers were inside. They sent this email to 25 known phishers. 10 of the phishers opened the word document and were presented with this. In addition, there was another link that said, “Actually, my account information is here.” 3 of the 10 clicked on that link. Even the phishers click links they shouldn’t.

What should be done? Who knows. It is human nature to trust people and we can’t get things done if every time someone sends us a link we open up a VMware image to view a link. So continue using the Internet the way you have been and remember, “These aren’t the droids your looking for.”

Quantifying XSS – Why Merchants Won’t Fix Their Cross-Site Scripting Vulnerabilities

Photo: bweech

Photo: bweech

From previous articles, you should be aware that Cross-Site Scripting (XSS) is an issue that is not going away any time soon.

Unlike it’s buzzword predecessor, SQL injection, Cross-Site Scripting is a difficult vulnerability to quantify. What is the risk of not resolving a Cross-Site Scripting vulnerability in your web application?

If you have recently gone through a web application assessment, the report most likely indicates the risk factor of having XSS is high. But, what evidence does the report writer have to support this statement?

Basic security teaches us that risk can be quantified as:

Risk = (Probability of the event occurring) x (The impact if the event occurs)

To support the consultants statement, we would need to identify the probability of an attacker using a Cross-Site Scripting vulnerability as an attack vector and what the impact is, if the user is exploited.

It is important to realize that XSS is a means, not an end. XSS is simply a transportation mechanism. It is used to facilitate the actual attack which could be system compromise or stealing a users session. The only limitation on XSS is that it operates in a browser environment.

Do to the numerous things an attacker can do with XSS, it is hard to quantify an impact for all XSS vulnerabilities. Since XSS has different severities in regards to impact, an organization should always choose the impact that is most severe. In other words, the worst-case-scenario.

If a user is exploited through an XSS attack, an organization can assume the attacker is doing the most damaging thing imaginable. Therefore, if a user is compromised from XSS, the impact is high.

Photo: stopnlook

Photo: stopnlook

Probability of the Attack Occurring
We have now identified that the impact of Cross-Site Scripting is high. But, what about the probability of it actually occurring?

It is difficult to find evidence of people using Cross-Site Scripting as an an attack vector? There are cases where XSS was used, in conjunction with SQL injection, to insert an offsite iframe into a web page in order to attempt a traditional overflow. Should these attacks be included into the equation for probability of it happening? Since it can be argued that these attacks used SQL injection, and not XSS for propagation, these attacks need to be excluded.

The only evidence I can find is Verizon’s 2009 Data Breach Investigation Report. That document however, doesn’t go into much detail about the specifics of the XSS attack.

Due to the lack of overwhelming evidence, XSS currently is not a common attack method. The probability of a Cross-Site Scripting attack occurring is low.

Cost-Benefit Justification of Fixing Cross-Site Scripting
Since it is difficult to quantify the cost of having an XSS, it is just as difficult to do a cost-benefit analysis on fixing XSS vulnerabilities.

Why should merchants spend money on fixing their XSS vulnerabilities when there is no supporting evidence of attacks occurring?

Until more web applications are compromised through XSS vectors and there is more evidence to support this happening, not much security budget will go towards fixing Cross-Site Scripting vulnerabilities.

Update: StrongWebMail was hacked using XSS. StrongWebMail paid out $10,000 for being breached. This has brought some media attention towards the issue.

Top Five Web Application Security Blogs

Today, I thought I would post great resources for information. If you want to be good at security, it means you need to be well read.

Here are the top five web application security blogs in no particular order.

  • Jeremiah Grossman – Probably the most read web application security blogger. Jeremiah reads all of the material so you don’t have too.
  • Rsnake / Robert Hansen – The other most read web application security blogger. Interesting Note: Graduated my alma mater.
  • Holistic InfoSec – Russ McRee’s blog. Russ puts people on the stove. He posts are controversial and exciting. According to ISS, Russ was one of the Top Vulnerability Discoverers in 2008. Keep an eye on him, it is interesting to see what he will do next.
  • Billy Rios – Also known as the XS-Sniper! Billy is behind some of the most innovative research as of late. He is the man behind Gifars and URI overflows. He is also known to smuggle olives on occasion.
  • Nitesh Dhanjani – Although he covers a wide range of topics outside of web application security, Nitesh continually blogs about topics that are thought-provoking.

60-day Cyberspace Policy Review Released and the Crowd Falls Silent

Today, the 60-day cyberspace policy review has been publicly released. Melissa Hathaway, the Cybersecurity Chief at the National Security Council, was in charge of leading the effort and was one of the keynote speakers at RSA.

Here are some of the main points of the document:

  • Establish a person in the White House who’s responsibility it is to report to the president on matters of cyber security (cyber czar position)
  • Review the laws and policies that are currently in place and issue more by tying the position into congress.
  • Increase public awareness about the risks of the Internet
  • Increase public education about how to be secure when conducting Internet activities.
  • Expand federal IT workforce (A.K.A. The government needs to pay more)
  • Executives need to be more aware of cybersecurity.
  • Government and Private Sector need to work together.
  • Laws regarding “collusion” need to be relaxed so that companies can work together more. (Scary Thought)
  • Work with International Governments to form jurisdiction lines.
  • Build a framework for incident response.
  • Enhance information sharing across government bodies for better incident response handling.
  • Improve Cybersecurity across all infrastructures

The policy review should upset anyone in security field. It points things out the obvious. I expect much more from our National Security Council. Metaphorically, this paper is like taking your car to a mechanic and asking for a full diagnostic for the health of your vehicle. After 2 weeks, you come back and the mechanic gives you a piece of paper with the phrase, “Your Car is Black.”

This review is a complete miss from a security standpoint. Hopefully, it will bring awareness to multiple parties on what needs to get done, but it doesn’t help to fix anything.

Government was designed to move slow. The founders of this country did not want the government to make any hasty decisions, hence bureaucratic red-tape. The Internet on the other hand is designed to move very fast. As soon as something becomes popular on the Internet, the next thing is being developed.

It is hard to comprehend a government body that would be able to keep pace with the Internet. In fact, as soon as the policy review was completed, the Internet has already changed.

What Motivates Hackers?

Photo: Kristin Bradley

Photo: Kristin Bradley

Attackers are motivated by multiple factors. Previously, “experts” believed most attackers were social outcasts who were writing malicious software out of their parent’s basement. These attackers were not driven by any particular motive. They were more driven by the problem-solving aspect. They wanted to know if they could do it. This idea that attackers are socially inept kids based in the United States is quickly becoming inaccurate.

Most security articles are focused on the means of the attack. They don’t address what attackers are actually after.

The four motivating factors for attackers that have been identified are:

  1. Financial Gain
  2. Notoriety
  3. Political
  4. Vengeance

Financial Gain
Hacking, Malware, and Worm Creation is a money making opportunity. Worms, such as Conficker, are being tied to organized crime based in Soviet republics.

The tightly managed criminal organizations behind such scams—often based in Russia and former Soviet republics—treat malware like a business. They buy advanced code on the Internet’s black market, customize it, then sell or rent the resulting botnet to the highest bidders. They extend the worm’s life span as long as possible by investing in updates—maintenance by another name. This assembly line–style approach to crime works: of all the viruses that Symantec has tracked over the past 20 years, 60 percent of them have been introduced in the past 12 months.

This shouldn’t be surprising. If criminals have no problem killing another human and taking their wallet, why would they have problems stealing massive amounts of money electronically?

However, organized criminals aren’t the only attackers driven by financial gain. There is also evidence of financially driven attackers being petty criminals. These are the types that don’t have a great understanding of what they are doing. They can be found on websites specifically setup for trading credit card numbers or other Personally Identifiable Information (PII). Some researchers, such as Rios and Dhanjani, have done research into this subgroup.


There is still evidence of hacking for notoriety. Most of these attackers are the “13-19” year old kids described above. The reason these individuals attack systems is driven by their want to become famous.

A recent example is the Mikeyy worm created by Michael Mooney of StalkDaily. This sub-group usually will justify their attacks by stating, “I wanted to bring awareness to the problem.” This is a constructed answer but demonstrates their want to become famous. They are clearly stating, they were the ones who wanted to bring awareness to the issue. These attackers typically have a Robin Hood type mentality of bringing knowledge to the uninformed.

These attackers are politically focused or driven by political means. This group includes “hacktivists” and foreign nationals driven to cause damage to an enemy country. Examples of these attacks are the Titan Rain and more recently Power Grid hacking.

Political motivation is frightening. Many countries will not deter attackers from hacking a foreign country. In addition, law enforcement has a hard time tracking down or arresting these type of attackers due to the lack of cooperation of foreign countries.


These attackers are the most dangerous. They will attack people who have somehow made them upset. Their driving factor is causing as much pain as possible for their victim.

These attacks typically target an ex-girlfriend or a celebrity. These are the electronic equivalent of breaking someones windshield. There is nothing that can really be done to prevent it other than to stop using the Internet.

How to Hack: Hacking by Numbers?!

Photo: stuartpilbrow

Photo: stuartpilbrow

A course will be offered this year at Black Hat entitled, “Hacking by Numbers: PCI Edition.” A quote from the appropriate literature:

The PCI Data Security Standard (DSS) has had a huge impact on the information security industry. One effect that it has had is to make annual penetration testing mandatory in some segments, and thereby spawn a whole new class of off-the-shelf penetration testers.

The term “off-the-shelf penetration testers” makes my stomach churn. It is my belief that hacking is more of an art than a science. Hacking is methodical, but takes a specific type of person to do it. Typical hackers are very methodical and analytic. In addition, ever hacker that I have ever met has a never-give-up mentality about them. This attribute is used as a feedback loop into the problem they are working on.

Sure some security work and/or security methodologies can be taught, but to be a “breaker” you have to have a certain personality type.

What are your thoughts on this? Feel free to tweet me about the topic. @miscsecurity