Showing posts with label fraud. Show all posts
Showing posts with label fraud. Show all posts

Saturday, April 21, 2012

Crimeware Immunity via Cloud Virtualization

There's a growing thought recently that perhaps remote terminal emulators and fully virtualized cloud-baseddesktops are the way to go if we're ever to overcome the crimeware menace.

In essence, what people are saying is that because their normal system can be compromised so easily, and that criminals can install malicious software capable of monitoring and manipulating done on the victims computer, that perhaps we'd be better off if the computer/laptop/iPad/whatever was more akin to a dumb terminal that simply connected to a remote desktop instance - i.e. all the vulnerable applications and data are kept in the cloud, rather than on the users computer itself.

It's not a particularly novel innovation - with various vendors having promoted this or related approaches for a couple of decades now - but it is being vocalized more frequently than ever.

Personally, I think it is a useful approach in mitigating much of today's bulk-standard malware, and certainly some of the more popular DIY crimeware packs.

Some of the advantages to this approach include:
  1. The user's personal data isn't kept on their local machine. This means that should the device be compromised for whatever reason, this information couldn't be copied because it doesn't exist on the user's personal device.
  2. So many infection vectors target the Web browser. If the Web browser exists in the cloud, then the user's device will be safe - hopefully implying that whoever's hosting the cloud-based browser software is better at patch management than the average Joe.
  3. Security can be centralized in the cloud. All of the host-based and network-based defenses can be run by the cloud provider - meaning that they'll be better managed and offer a more extensive array of cutting-edge protection technologies.
  4. Any files downloaded, opened or executed, are done so within the cloud - not on the local user's device. This means that any malicious content never makes it's way down to the user's device, so it could never get infected.
That sounds pretty good, and it would successfully counter the most common flaws that criminals exploit today to target and compromise their victims. However, like all proposed security strategies, it's not a silver bullet to the threat. If anything, it alters the threat landscape in a way that may be more advantageous for the more sophisticated criminals. For example, here are a couple of likely weaknesses with this approach:
  1. The end device is still going to need an operating system and network access. As such it will remain exposed to network-level attacks. While much of the existing cybercrime ecosystem has adopted "come-to-me" infection vectors (e.g. spear phishing, drive-by-download, etc.), the "old" network-based intrusion and automated worm vectors haven't gone away and would likely rear their ugly heads as the criminals make the switch back in response to cloud-based terminal hosting.
    As such, the device would still be compromised and it would be reasonable to expect that the criminal would promote and advance their KVM capabilities (i.e. remote keyboard, video and mouse monitoring). This would allow them to not only observe, but also inject commands as if they were the real user. Net result for the user and the online bank or retailer is that fraud is just as likely and probably quite a bit harder to spot (since they'd loose visibility of what the end device actually is - with everything looking like the amorphous cloud provider).
  2. The bad guys go where the money is. If the data is where they make the money, then they'll go after the data. If the data exists within the systems of the cloud provider, then that what the bad guys will target. Cloud providers aren't going to be running any more magical application software than the regular home user, so they'll still be vulnerable to new software flaws and 0-day exploitation. This time though, the bad guys would likely be able to access a lot more data from a lot more people in a much shorter period of time.
    Yes, I'd expect the cloud providers to take more care in securing that data and have more robust systems for detecting things that go astray, but I also expect the bad guys to up their game too. And, based upon observing the last 20 years of cybercrime tactics and attack history, I think it's reasonable to assume that the bad guys will retain the upper-hand and be more innovative in their attacks than the defenders will.
I do think that, on average, more people would be more secure if they utilized cloud-based virtual systems. In the sort-term, that security improvement would be quite good. However, as more people adopted the same approach and shifted to the cloud, more bad guys would be forced to alter their attack tools and vectors.

I suspect that the bad guys would quickly be able to game the cloud systems and eventually obtain a greater advantage than they do today (mostly because of the centralized control of the data and homogeneity of the environment). "United we stand, divided we fall" would inevitably become "united we stand, united we fall."

Saturday, June 27, 2009

Making Money with Your Own Stealthy Botnet - Part II

Continuing on from yesterdays discussion of making money from botnets the stealthy way using a customer advertiser approach, lets look at another "if I had a big botnet I'd..." vector for making real money.

2. Pay-per-Installs
Pay-per-installs are a more recent permutation of click-based advertising payment schemes, except in this case the affiliate payment model is premised on getting others to install a piece of software.

As the owner of a Web site you get paid a small amount for each time a visitor to your site downloads a software package and installs it on their computer. Sounds dubious to you? Well, yeah, it's an odd business model, but there are quite a few service providers in this realm - so it looks like someones making money from the system somewhere. (note: there's a more detailed discussion on how the pay-per-install business operates at the end of this blog).

Exploiting this payment system with a botnet appears to be pretty obvious. With 50k victim computers under your control you simply remotely install the software packages on each of them and collect the cash at the end of the day. It's so obvious in fact that there are quite a few botnet operators out there already doing this. Early last year I was alerted to an enterprise-level victim that had several thousand infected hosts worldwide and was trying to figure out why these hosts were routinely installing and installing software - unaware that they had been compromised and were under the control of a bot master conducting a pay-per-install fraud.

But, even though this particular scam is already in operation, it looks to me to be an interesting way of making money from a botnet. And, based upon what I've seen and heard, there is still quite a bit of room for "improvement".

If I owned a botnet of 50,000 victims, I'd aim to make it more stealthy than whats out there today. Some obvious advancements would include:
  1. Stealthy installation. With the bot agents already operating with administrator or system-level permissions, I'd make sure that an package installations are done without any user visible prompts and confirmations. In some cases this may be quite difficult because several of the more popular (and higher paying) pay-per-click affiliate systems attempt to thwart "illegal" installation of their software and have hard-coded clickable popup boxes or prompts for user supplied information. That said, most bot agents today have access to scripting languages and I'm certain I could automate the clicking and filling in of any forms - so that's not going to be a problem.
  2. Log management. From what I've observed so far, it's going to be important to manage the application and security logs on the host. I'm going to have to either prevent my software installations from being logged and audited, or to erase any entries that crop up. This would be pretty easy for home PC's, but may be more difficult for enterprise victims that report their logs centrally. In which case, going with the former method (preventing the logs from being updated) is going to be preferable. Again, this is straight forward as long as my bot agent is operating with system permissions.
  3. Timed uninstall. I'm going to want to have a mechanism for automatically uninstalling any software packages that I've installed. Ideally I'd set that up in advance and ensure that there's some kind of scheduling ability in my bot so I don't have to remember to uninstall it myself (or if I temporarily loose C&C over the host at any stage).
  4. Fatal Error Simulator. It'll be helpful to have a component that'll generate a "fatal error" kind of message to the user of the computer. Ideally I'd aim to install any pay-per-install software packages stealthily and when the user is not currently interacting with the computer (e.g. monitor if the screen is locked, a screen-saver is running, or whether the mouse and keyboard haven't been tuched for 10+ minutes) - I might even monitor the local hosts time and do my installations in the wee hours of the morning. Regardless of the scheduling aspect, throwing up a fake fatal error message either instructing the user to reboot (or timing down to a forced reboot) or just blue-screening the host, will be handy if any of the packages require a reboot to function (e.g. some packages require a reboot before they phone-home and the pay-per-install vendor ponies up the money).
  5. Hide the popups. It seems that many of the better paying pay-per-install packages are effectively spyware with ad popup capabilities. I'd definitely want to make sure that those popups never appear on the screen and bother my poor victim user (I'm trying to be stealthy remember) - and I'll probably want to "click" on a few of the ads just in case someones monitoring whether the software was actually installed legitimately and is being used.
Counting the Money
Given the investment necessary for configuring my botnet to conduct this pay-per-install fraud, how much money could I be expected to make?

If I was to go with one of the affiliate providers, here's what I'd be looking at on a per package install basis (assuming the majority of my botnet is in the US)...
Actually the selection process isn't quite as obvious as it may seem. There's all sorts of "hidden" criteria for payment with the pay-per-install organizations that appear to offer the most. Regardless, lets knock off the first two and see what $0.13 to $0.60 could earn me...

Based upon a botnet of 50,000, lets assume that I can roll out the pay-per-install packages to 90% of them - that'll yield between $5,850 and $27,000. Not too shabby. With a bit of luck I can install a new package at least once per week, and uninstall older packages after I've been paid for their installation (allow 4-6 weeks). That means I could potentially be earning something like $20k-100k per month!

I suspect however that I'd have to split my pay-per-install affiliation amongst multiple providers as they'd soon get wise to the fraud if they had to hand over that amount of cash on a monthly basis - so I'd probably have to throttle things back a little if I'm to remain under their detection radar. I'd probably aim to earn about $10k per month through this botnet money-making scheme without too much fear of being spotted. That said, some of these pay-per-install vendors appear to have really open minds - and aren't shy of doing business with known botnet operators.

That's a reasonable return on my investment in setting up the delivery mechanics of the fraud. And there's no reason why I can't continue to use the botnet simultaneously for other fraud schemes. It's not going to make me rich, but it'll be handy to cover the costs of growing my botnet further.

The Pay-per-Install Business
When I first encountered pay-per-install vendors, it was back in the mid-1990's and shareware was all the craze. Some software vendors cottoned on to the fact that they could make more money if their new application was widely available and people installed it - thereby eventually registering the software or purchasing the subscription. Given how competitive (and crowded) the shareware distribution system was back then, paying a BBS operator or Web master to promote their software above other products made a lot of sense. Payments of up to $20 per successful installation and user registration weren't uncommon.

Since that time, the model has been refined and business permutations compete against each other. There are even some pay-per-install companies that have turned this model in to a successful affiliate marketing model.

The software being distributed by many of these pay-per-install vendors today isn't precisely something most computer users would want running on their computers. If it's not an actual virus (or bot), then it's going to be spyware or adware. More than likely, it'll be the latter - as this is how many of the pay-per-install operators make their money.

Getting started in this business as an affiliate is simple. There are plenty of sites and forums providing advice and tactics for making money installing this unwanted software. A quick google for "pay per install forums" will take you to over 12,000,000 sites/pages of information and advice.



Then there are several review sites - complete with star ratings of the pay-per-install vendors.



Finally, here's the FAQ from one such pay-per-install vendor (which I don't really believe in their non-virus claims - but you get the picture).
  1. What we pay for?

    We pay for our promotional software installation with your affiliate ID.

  2. Are you making traffic quality checks?

    We are making the analysis of each affiliate traffic. If in two weeks we do not leave on a recoupment point, we keep the right to suspend work with an affiliate, we pay to him for the poor-quality traffic ( exactly so much how many we earn) and leave him.

  3. Is your software a virus?

    Emphatically - no ! Our program does not inflict harm the computer of user and steal no personal information. The primary purpose of our software is advertising (such as popup advertisements or hijackin search result) and nothing anymore.

  4. Do you allow SPAM traffic?

    NO, exposed affiliates will be blocked and won't paid.

  5. Do you have active referral program?

    Up to know we don't have referral program for our affiliates, but we are working on such program implementation.

  6. What is your actual install rates?

    Basic rates are listed here, but after week of stable installs flow you rates may be reconsidered by contacting support.

  7. What is your minimum payout?

    The minimum payout for everybody is $10.

  8. What payment methods are available?

    Webmoney (0.8% payment commision)
    WIRE transfer ($50 payment commision)
    ePassporte (1.8% + $2 payment commision)
    PayPal (3.5% payment commision)

It's interesting to note that the grammar and spelling doesn't appear to have come from a native English speaker, and that this particular site is hiding it's registrant details via PrivacyProtect.org.

Thursday, June 25, 2009

New Bot-powered Pharmaceutical Scam Network

The other day we staggered across a strange botnet. It was only small as far as IP addresses were concerned, but gigantic as far as domains under management (greater than 25,000 currently in use). The cost of registering that number of domains is a significant investment by the botnet operators - at $20 each to register, you're looking at $500k in setup costs alone).

But the strangeness doesn't end there. The botnet is being used for pharmaceutical scams (i.e. Canada Drugs), but the DNS lookup process is messed up. Somehow the botnet operators have figured out how to manipulate the .com root servers in to doing some weirdness - and having them act as the authoritative resolvers for the 3LDs.

I'm not sure how this situation arose, but the criminals behind this are making good use of the flaw/exploit/manipulation. What they now effectively have is a system that prevents the good-guys from shutting down the resolution of where their scam Web sites are. Not good.

I'm still looking in to how this arose and what the real (longer-term) ramifications of this are. But its new to me and definitely in the strange/weird department.

I've posed a full blog about this botnet over on the Damballa site - Strange Bot-powered Scam Network. Take a look at whats going on.