Posts Tagged ‘malware’


Paving Over the Proprietary Web: The Java Security Bigger Picture

Written by Andrew Jaquith. Posted in Blog Post


Perhaps you’ve heard about the recently disclosed Java 7 zero-day exploit. The flaw allows a remote attacker to take complete control of a computer. It has been incorporated into many exploit kits. The Department of Homeland security regards the Java exploit as sufficiently serious to recommend “disabling Java in web browsers until adequate updates are available.” Oracle’s fixes — aren’t.

Many of my colleagues at other security firms have spilled a lot of ink describing why this particular Java exploit is bad. It is indeed that bad; Apple, for example, has forced down an update that blocks the Java 7 plugin from executing in the browser at all, at least until Oracle is able to distribute an update. If you are in the habit of keeping Java switched on in your browser, you should turn it off — of course. But that isn’t always possible. Client-side Java, for example, powers GoToMeeting. Many other companies — including my own — rely on client-side Java for critical functions. So one cannot simply rip it out, or mandate that it be banned. Reality has a habit of messing up the best-intended recommendations. But make no mistake, at some point very soon Java on the client needs to go. CIOs, please take note.

Client-side Java is part of the web’s proprietary past, and its time is ending. That proprietary past also includes ActiveX and Flash, two other technologies that saw widespread adoption in the early 2000s. That all three of these technologies came of age at roughly the same time isn’t a coincidence; they all filled gaps in the web experience. ActiveX was Microsoft’s way of adding native client functionality to a then-crude web experience; client-side Java (Swing, Java Web Start etc) did the same. Flash and its cousin ShockWave provided smooth video and animations.

Since 2005, though, the native web has changed dramatically, and for the better. HTML 5, CSS and JavaScript toolkits have been the major catalysts of a revolution in web design. The canvaselement added to HTML 5, for example, allowed standards-compliant browsers to draw shapes, create and fill paths, and animate objects. This, plus the video element, freed designers from needing Flash. Cascading Style Sheets (CSS) Levels 2 and 3 gave designers increasingly pixel-perfect control over the placement and appearance of content — a task made even easier with CSS pre-processors such as LESS and Sass, and with kitted CSS assemblies such as Twitter Bootstrap. On the JavaScript front, third-generation toolkits such as jQuery made it simple to make websites dynamic and responsive. You can do all of these things for free, without needing to buy any of the various Studios from Adobe or Microsoft.

The slow-motion revolution in how the Web is made means that the raîson-d’être for proprietary web technologies is going away. Like a lumbering concrete mixer, HTML5 and JavaScript are slowly paving over the parts of the web that had previously been occupied by Flash, ActiveX and Java. Ironically, the vendors of these proprietary technologies have, in their own ways, added limestone, clay and water to the paving machine.

Microsoft, for example, turned an entire generation of web developers against it with its long, and ultimately fruitless, resistance against robust CSS support in Internet Explorer. Although modern versions of IE are highly standards-compliant, Internet Explorer did not pass the CSS Acid3 test until September 2011. Any web developer who has been working with CSS for more than 5 years, for example, can probably regale you with stories of massive hacks needed to allow older Microsoft browsers to work with standards-based websites.

The roots of Adobe Flash’s decline are a little different. Nothing was “broken” with Flash, functionally speaking1. Two related events resulted in a decline in Flash usage: Steve Job’s public refusal to add Flash support to the iPhone and successor iOS devices; and Google’s decision to convert its vast library of YouTube clips to HTML 5-compatible WebM and H.264 formats.

These actions, plus the increasing viability and efficiency of WebM and H.264, meant that you didn’t need Flash video any longer. This has clear implications for customers. For customer-facing websites, you can (and should strongly consider) retiring Flash video in favor of H.264. This is a quick win; the re-encoding process is relatively quick and painless. That said, the need is not as urgent compared to Java. Adobe’s security team (under the leadership my former @stake colleague Brad Arkin) has upped the tempo of bug fixes, adopted auto-update, and is taking security seriously enough that Flash has become less risky than it had been. Still, if you can remove a dependency on a third-party component that needs to be maintained and updated in addition to the base operating system, why wouldn’t you?

Java, on the other hand, is simply a mess. From a pure features perspective, Java’s caretaker parent, Oracle, no longer employs the kind and number of Java engineers that will keep it up-to-date — never mind put it back on the cutting edge. Most of the Java engineers and visionaries such as James GoslingJosh BlochTim BrayAmy Fowler, and Adam Bosworth — the people I learned from and looked up to while I was learning Java J2EE — left long ago to greener pastures. Although server-side Java is still widely used, nobody I know would consider it for greenfield development for use with a browser.2

From a security standpoint, it is hard to see why Oracle would be Johnny-on-the-spot with security fixes. As my other (!) former @stake colleague David Litchfield has pointed out, the company doesn’t have the best track record on security. We can reasonably assume that fixing client-side Java security holes isn’t anywhere near the top of Oracle’s priority list. And even if it becomes so because screaming customers demand it, legacy products get legacy engineers. That’s just the way it is.

The same goes for Microsoft’s ActiveX. Developers don’t use it for new web-based projects, and the company has for several years recommended that developers use other technologies3 to make dynamic websites. The risks associated with ActiveX continue to be high, no doubt because ActiveX controls are basically chunks of native code written by various vendors of varying skill, remotely triggered by websites that may or may not be under the user’s control. (What could go wrong withthat?) To be sure, Microsoft has done as much as any vendor in the industry to set the standard for responsible and secure development practices. Over the years, they have responded relatively quickly to the various ActiveX security issues that have popped up over the years. But as with client-side Java, it’s legacy technology maintained by legacy engineers.

It is much, much easier to talk about how the slow-moving concrete machine that is the modern web — HTML 5, CSS, and JavaScript — will slowly pave over the proprietary web. It is harder to state with confidence what it will mean for security. However, one may hazard a few guesses. The decline of these three technologies should increase the overall level of security over time. Logic dictates that a browser festooned with fewer proprietary plugins is a more secure browser. Put differently: migrating older websites to use CSS, HTML 5 and JavaScript support will have the effect of concentrating the attack surface by reducing the number of parties who must defend that surface. Over time, the broad public ought to be better served by having Apple or Google or Microsoft be responsible for the entire web browsing experience — including security.

But in the short term, it won’t be so clean. Based on vulnerability counts — an imprecise metric at best — the “younger guys” don’t score well. For example, the US National Vulnerability Database shows that the WebKit browsing engine had over 198 disclosed vulnerabilities last year. Internet Explorer? Just 61. Meanwhile, ActiveX, Java and Flash had 73, 169, Flash 67. I draw no other conclusions from these data, other than the simplest one — increased use of native browser capabilities is likely to increase risks in the short term, even as the decreased use of proprietary technologies decreases it. At some point the two lines will cross.

In the meantime, the cement truck keep rumbling.

1 Functionality aside, Flash’s security track record has been poor for a while.

2 Java development is alive and well on the Android platform, of course.

3 It’s fair to say that Microsoft has been all over the place on this subject over the last 10 years: DHTMLXAML/SilverLight, and now Windows 8-style apps.


The Year in Review: 2012

Written by Andrew Jaquith. Posted in Blog Post


As the song goes, It’s The Most Wonderful Time of the Year. It’s the time of the year we write out our holiday cards, buy presents, think kind thoughts of our friends and family, and wax nostalgic.

Security is a big enough deal that it, too, warrants reflection and (dare I say it), a little bit of nostalgia. It’s the gift that keeps on giving. In that spirit, let’s dig up some of the tastiest chestnuts from the preceding 11 months, and gently roast them where appropriate. Given my sense of humor it’s going to be, shall we say, a dry roasting.

Here’s what got our attention in 2012. As is customary and appropriate, we spent a lot of time worrying about malware. The cloud — with all of its opportunities and challenges — was the second most important topic on our minds, along with mobile security. As you might expect, given our customer base of over 1,800 banks and credit unions, we analyzed financial services topics in depth. A variety of other topics got our attention, notably October’s National Cyber-Security Awareness Month and Mac security.

Each of these topics take time to review. So, let’s get nostalgic.


In 2012, it was clear that malware continued to be a problem for many companies. Of all of the topics we wrote about in 2012, we wrote about malware the most. Malware concerns came in four categories: web malware, new attacks, legacy malware and administrator-targeting malware:

  • Web malware — because of the ubiquity and reach of ad networks, attackers have made it a priority to attempt to infiltrate and infect ad servers. My colleagues, analysts Evan Keizer and Grace Zeng, wrote extensively about a banner-add infection campaign that caused to inadvertently serve malware. Unfortunately there are no easy fixes for banner infections; webmasters (and their colleagues in marketing) must be extremely vigilant.
  • New attacks — the Flame malware family, which some have called the most sophisticated malware ever discovered, was discovered by our friends in May at Kaspersky and widely covered. We thought it was notable enough to write about, too. Just to show that I don’t have a monopoly on bad puns, my colleague Rick Westmoreland asked, “Flame: Is it getting hot in here?
  • Legacy malware — we saw campaigns targeting old-school programs like Symantec’s venerable PCAnywhere. (If you are asking yourself, “do they still make that?” you aren’t alone.) Malware targeting Microsoft’s RDP protocol also spread rapidly; we felt it was dangerous enough to issue an advisory.
  • Administrator targeting malware — the most insidious malware campaign we saw in 2012 was one targeting Plesk, an administrative console for website operators. This was a little scarier than most campaigns because it obviously targeted people who have a high level of privileges already — your IT guy. This is the kind of thing that presages an industrial espionage campaign, a topic I covered at length in my webinar “The Hype and Reality of APTs,” something you should watch. (Ed: I am not joking. Really, go watch this; it deflates the APT hype balloon.)
In addition, we gently ribbed the anti-virus industry in an amusing post (Ed: to me, anyway) called “The Best and Worst Data-Driven Security Reports of 2011,” where I made fun of the silliness that comes with the periodic rash of AV “threat reports,” while celebrating the genuine good stuff, such as the Verizon Data Breach Investigations Report.

Cloud security

In 2012, Cloud security topics were right up there with malware in our consciousness. Call me crazy, but to me “the cloud” is a fancy name for hosted services mashed up with virtualization, and juiced up with instant-on provisioning and elastic usage billing. It’s a new — and welcome — twist on an old concept. Companies want to use the cloud in areas where it makes sense — for hosted email, productivity, and sales automation — but they want to do it only when they can be assured that their data is secure.

My colleague, Grace wrote about a key class of cloud risks: the security of servers in the cloud. She performed experiments where she placed 12 unprotected servers in the Amazon cloud and watched what happened. The headline: on average, your new cloud servers will start seeing scans, probes and potential attacks within an hour! Scary stuff — if you haven’t already, you should read these posts.

On the positive side, Perimeter created a series of video blog posts called the Cloud Owners’ Manual that took strong points of view on how companies should think about the cloud, and what they should be asking their vendors. Looking spiffy in a suit, I spoke on camera about key customer concerns about the cloud, and gave prescriptive guidance on the cloud in general, customer fees, data protection, data privacy, contractual terms, and contract termination. As an analogy, I compared cloud security requirements to car safety belts. Did you know that since the advent of car safety technology, based on US DOT official statistics, people now drive faster and have fewer accidents? It shows how safety gear is a precondition for faster, safer driving. To put it differently: confidence requires security. And by analogy: so it is with the cloud.

Mobile security

From iPhones to iPads to Galaxies, mobile devices continued to move to the top of IT security managers’ list of concerns. Beyond the sheer proliferation of devices, we observed four key trends:

  • Bring your own device. When I was an analyst at Forrester, my then-colleague Natalie Lambert coined the term BYOD and wrote quite a bit about it. That was four years ago. Now, it’s the hottest thing in IT. What do companies do about it? For our part, Perimeter answered the bell in September when we unveiled our Cloud MDM service in partnership with AirWatch. In the service, we included strong default policies and a unique BYOD Kit that provides prescriptive guidance for all of the areas employers need to worry about: data rights, support, confiscation, and many other topics. We think the right solution to BYOD is holistic, and encompasses the domains of policy, technology and law.
  • Developer ecosystem concerns. In September, developer Blue Toad had 12 million Apple unique identifiers (UDIDs) stolen. This shined a spotlight on a fragmented, shadowy part of IT: the thousands of smallish, contract mobile app developers, very few of whom are likely following mobile app security best practices. Watch for this topic to explode in 2013 as the Mobile Backend-as-a-Service (MBaaS) category heats up.
  • Data privacy. In the first quarter, we saw a controversy erupt over the Path app, which was uploading customer address book records to their servers unbeknownst to customers. I called Path an example of “nosy apps” and characterized data privacy as the “third rail of mobile.” These kinds of negative stories had an immediate impact on handset makers. Apple, for example, added significant opt-in controls to iOS6 that require customers to explicitly authorize app access to address books, photos, calendars, tasks, FaceBook account information and much more.
  • iOS has been a benefit to security. Speaking of Apple, did you know that iOS is now over 5 years old? In that time, customers have gotten used to the idea of vendor-controlled app marketplaces, digitally signed and trusted operating system runtimes, and locked-down devices. We have Apple to thank for popularizing the concept, building on the kinds of concepts RIM and Symbian had initiated. See my in-depth 5-year iOS security retrospective for details about why I think iOS is overall an huge net win for companies and consumers alike.

Financial services

Banks, credit unions, broker-dealers and other financial institutions continue to be a significant part of Perimeter’s customer base. We noted many, many threats to financial services customers in 2012. The rash of denial-of-service (DDoS) attacks in September prompted us to issue a critical advisory to our customers. We followed up on the DDoS story in October; my colleague Rick Westmoreland called it “the new reality” for financial services firms.

In July, we inaugurated our first-ever Financial Services Threat Report for the first half of 2012, which described the most important threat trends our customers were facing in the year to date. We will be doing more of these reports, and our second-half report will be coming out after year-end. To help our credit union customers, Andrew wrote a three-part series on credit union security topics.


Beyond these four main themes, Perimeter noted several other trends. We weighed in on this newfangled concept called “cyber security,” which is what happens when government-type people get their hands on an otherwise perfectly acceptable phrase — that thing that most of us used to call “information security” — and dumb it down. I suppose cyber-security is, to paraphrase Deng Xiaoping, Security With Government Characteristics.

Whatever you choose to call it, we helped celebrate National Cyber-Security Awareness Month in October with four posts by my esteemed colleague Mr Mike Flouton:

Midway through the year, Perimeter E-Security CEO Tim Harvey and actor/entrepreneur/restauranteur Robert De Niro hosted an exclusive New York event for 75 select partners and customers. The event featured an inspiring talk by two active duty Navy SEALs about building a high-performance, elite team capable of executing the most difficult missions. Tim’s summary of the event is here — in which he describes the key ingredients for success. For the record, I spoke at the event as well, but let’s face it: De Niro and the two Navy SEALs were hard acts to follow. It was a great event, though!

Lastly, Perimeter wrote about those devices your executives and developers are probably now carrying: Macs. In October, we released a survey showing that Mac usage is up, and that security concerns are increasing. Earlier in the year, alerted customers to something rather rare but important: real-life Mac Trojan outbreak in the wild: the Flashback Trojan.

Wrapping up

As I noted at the top of this post, security is the gift that keeps on giving. That’s good and bad. It’s bad for the obvious reason because the threats, concerns and challenges that got our (and the industry’s) attention affect companies and their customers everywhere. If security were a solved problem, we wouldn’t need to spend the time, attention and effort that we do.

I choose to be positive, though. Security threats and challenges are also good things. They remind us that, as professionals, we need to keep upping our game. New business frontiers such as mobile cause us to expand our horizons, become more involved with our colleagues and take the longer view.

As we look ahead to 2013, we are thankful for the continued support of our customers, colleagues and families. We at Perimeter wish you, dear reader, all the best this holiday season.


Perimeter E-Security 1H 2012 Financial Institution Threat Report

Written by Grace Zeng. Posted in Blog Post

By Grace Zeng, with David Coffey and Andrew Jaquith

Summary: Perimeter E-Security provides comprehensive security services to financial institutions of all sizes. In this report for the first half of 2012, we summarize security incidents based on data from 861 financial institution customers. During that period, 1,619 likely and confirmed compromises were detected. Of these, 43% targeted small, 38% targeted mid-sized, and 19% targeted large institutions. In total, 483 financial institutions were affected by those incidents. A majority of our financial customers (56%) experienced at least one security incident in the last six months. Large institutions had the highest average number of incidents per institution: six, about one per month. Our security services blocked about one third of all incidents, preventing damage to customers’ assets. Based on our analysis, Trojan horses and the Blackhole exploit kit are the most common threats facing financial institution customers today.

Monthly incident trends

Perimeter processes about 1 billion raw security events per month. We distill these events down to approximately 120 thousand potential security incidents. Among those incidents, a majority are low-level — that is, they are informational or reconnaissance related. A smaller number are likely or confirmed successful system compromises — what we call medium- and high-level incidents. Throughout this report, a “security incident” refers to these two types. A Perimeter security analyst analyzes every one of these. When a customer suffers a security incident, it is likely that one of their computing assets such as a desktop, server or other resource has been — to put it plainly — 0wned.

The Perimeter security team analyzed over 1,600 incidents — likely and confirmed compromises — in the first six months of 2012. From the monthly trend graph, we can see that the number of security incidents increased steadily from January to May before slightly declining in June. It appeared that threats and attacks are seasonal: more active in spring (Mar to May) than in winter (Jan and Feb).

Impact on financial institutions

Perimeter protects approximately 1,800 financial institutions. Our financial customers’ businesses range from banking and brokerage to credit unions, savings and loans and insurance. Our financial customers consist of 62% small institutions, 29% mid-sized institutions and 9% large institutions. We define small institutions as having assets less than $25 million; medium-sized between $25 million and $1 billion, and large institutions above $1 billion.

The chart below shows the distribution of incidents among our customer base. The plot shows percentages of financial institutions that had at least a certain number of incidents. In total, 56% of our financial customers experienced at least one incident. At one institution — the outlier at the right side of the chart — we detected 28 incidents over the past six months.


When analyzing the incidents by size of institution, we found additional patterns. In the past six months, 69% of our large financial customers experienced at least one incident. Midsize and small institutions, 63% and 51%, respectively, experienced one incident or more. On average, each institution suffered from about three incidents.

Of the top 10 customers that suffered the most security incidents, four are midsize (assets between $25 million and $1 billion) and six are large (assets greater than $1 billion) institutions. On average, each large institution had six incidents; each midsize had four; and each small had three. We believe large institutions are disproportionately targeted because they have large attack surfaces and can garner attackers larger financial gains. Although small institutions are not usually primary targets of attackers, they can serve as stepping stones for larger-scale attacks. And crucially, small institutions are most vulnerable to financial losses, and  may not be able to survive even one attack.

Approximately one-third of all security incidents were successfully blocked by our in-cloud and on-premise security devices. The rest were detected after-the-fact by our security monitoring systems.

Attacker countries of origin


Although Perimeter is not as wildly enthusiastic about “top attacking country” metrics as some — we do not suffer from congenitally nervous urges to “name and shame” former colonies, for example — the country origins of attackers help confirm hunches and things we already know.

Of the security incidents we observed, attackers’ IP addresses are distributed across 50 countries across the globe. The heat map below plots these countries with respect to the number of offending sources.  From a percentage perspective, more than 55% of attacks and threats originated from inside the United States. We expect that the main reason is that the financial institutions under scrutiny are almost all US-based. In addition, many of our customers commonly block traffic to and from non-US IP address ranges. We noticed that many users picked up malware from visiting legitimate US web sites.


Threat highlights

Financial institutions are particularly vulnerable to cyber crimes such as phishing and identity theft. We have seen numerous security incidents that have resulted in significant losses to the victim institutions.  A common propagation vector is targeted phishing emails addressed to employees with privileged account access. Once the recipient opens the link or the malicious attachment in the email, malware (in most cases, a Trojan) is installed. Sensitive account information is collected, which leads to unauthorized monetary transfers and customer data compromises. Based on the six-month incident data, Trojans turned out to be the major threat category facing financial institutions. As shown in the top 10 threat list, more than half of the incidents we observed were Trojan-related infections. Two threats on the list are particularly noteworthy: the Blackhole exploit kit and the ever-popular fake Anti-Virus. Details on each follow.

Blackhole exploit kit

The Blackhole exploit kit was the top threat plaguing our customers over the past six months. According to AVG Technologies, the Blackhole kit is the most popular toolkit in the cyber-underground. AVG’s Q2 threat report indicates that the Blackhole Exploit Kit makes up over half of detected malware; our figures agree broadly with AVG’s.  The Blackhole kit is installed on a server controlled by a cyber-criminal. When an unsuspecting user visits a compromised page or clicks a malicious link in a spam message, the page or link redirects (usually via <iframe> tags) the user to the server. The server hosts obfuscated code that delivers various exploits targeting vulnerabilities in browsers and their popular plug-ins such as Adobe Flash, Adobe Reader and Java. Once an exploit is successful, the victim machine loads and executes malicious payloads, and downloads additional component if needed.

Perimeter has been closely following this exploit kit since its emergence.  We observed that the ease-of-upgrading helps to make the kit prevalent; zero-day exploits are constantly added to the kit.  For example, a Java vulnerability was disclosed in mid-June and an exploit leveraging this flaw was made available in early July. Blackhole kit also rapidly evolves the way it spreads to web servers. In its recent campaign in late June, web servers were compromised by exploiting the Plesk SQL injection vulnerability.  Many web pages were infected with contaminated JavaScript files which loaded the Blackhole exploitation.  To defend against this ever-evolving exploit kit, we have implemented several protection mechanisms for our customers:

  1. Network-based anti-virus is equipped with JavaScript/iframe signatures to offer client-side protection
  2. Web security (content filtering) can block domains that host Blackhole exploit kits
  3. Multiple correlation rules in our SIEM match patterns of related IP addresses, domains and file names.  Please refer to our recent blog post for details.

Fake Anti-Virus

Rogue anti-virus is a form of Internet fraud that tricks users to install or purchase fake AV programs, to “help” remove non-existent threats in their computers.  These malicious AV programs usually introduce Trojans to the victim computer to harvest personal information. Fake AV has been one of the most prominent online threats in recent years. Purveyors of fake AV push it through a variety of channels:

  • Spam emails with links or attachments
  • Malicious advertising and compromised ad networks
  • Web pages containing exploits
  • Search engine optimization (SEO) poisoning

We have been closely monitoring fake AV activities for our customers and observed a rash of campaigns that led to dozens of infections this May. Early June, we discovered that Major League Baseball and a few other legitimate websites fell victim to a compromised ad network and served up fake AVs to their users.  We managed to pinpoint a specific ad on MLB’s website that embedded an iframe redirection to a malicious server. This server then pushed fake AVs from several Indian .in domains to users.  We published detailed analyses of these campaigns here and here.  To protect our customers, we immediately added null-routes to IP addresses malware-hosting domains resolve to. We also have created several correlations that keep updating to detect new campaigns.

Protecting financial institutions

As our review of the first half of 2012 shows, financial institutions continue to be under attack. To protect our financial customers from attack, we provide multiple layers of defense: firewalls, web content filtering, IDS/IPS, AV tools and SIEM. Each plays an important role in defending against state-of-the-art threats.

Perimeter highly recommends our financial institution customers take all necessary steps to safeguard machines and follow security best practices. Customers should:

  • Never open unexpected email attachments or click on any links in suspected emails
  • Never supply any personal or account information as a result of an email
  • Always keep the operating system and software packages (browser and AV programs in particular) up-to-date
  • Always disable and/or uninstall unused services on endpoint machines, servers and network devices
  • If possible, block ads in the browser, or use web content filtering services

Dan Carter and Mike Flouton contributed to this report.


New exploit campaign targeting Parallels Plesk — admins, beware!

Written by Richard S. Westmoreland. Posted in Blog Post

Last week, the Perimeter Security Operations Center added specific siem detection for an active exploit kit campaign dubbed RunForestRun.  An updated diary article from SANS provides a good summary ( of the campaign:

The campaign uses an underground web server called Sutra TDS that makes analysis difficult.

Two different sets of URLs are used for redirection, and successful redirection only happens when the cookies from the previous stage are set (this evades direct analysis of the final URL)

Successful exploitation via Blackhole Exploit Kit drops ZBot (ZeuS)

Unsuccessful exploitation serves Fake-AV in local language

As we dove deeper into backtracking the jumping point for this campaign, we confirmed that these exploits originated from legitimate sites with compromised JavaScript files.  The sites were compromised due to vulnerable versions of Parallels Plesk and ongoing attacks against the site management platform. The vulnerable versions are prior to Plesk 10.4. Unmask Parasites summarized the attacks as follows:

Feb-Mar 2012, attackers gained admin access to Plesk, put in backdoors and stole user databases (which contained passwords in plaintext)

June 2012, hackers use stolen credentials to modify js scripts with obfuscated code

The .js scripts are appended with a heavily obfuscated routine that causes remote content to be loaded when the site is visited:

...obfuscated code...
...obfuscated code...

In other cases, we have observed similar code prepended to HTML files. We are still verifying if this is part of the same campaign or another compromise altogether.  Other 3rd party analysis of the campaign also shows other exploit kits getting used, such as Nice Pack and RedKit.

The script generates a pseudorandom domain with a .RU suffix, and at the start of the campaign loads /runforestrun?sid=cx from that domain.  At the time of this writing the URL is now /runforestrun?sid=botnet.

Based on referral information, the page either continues a series of redirections, or displays a fake error that the domain was suspended.

Recommendations for customers

The RunForestRun campaign is particularly dangerous because it targets sites running Plesk. Who are the typical users of Plesk? Privileged administrators, of course. As such, we regard this campaign as a deliberate strategy to compromise highly privileged employees. That places it in a more serious risk category than your garden-variety malware campaign.

For IT administrators who use Plesk to manage their websites, we recommend that you:

  • Confirm you are not running versions prior to 10.4.
  • If you have been using an older version, upgrade immediately, review all your web files for compromise, and reset your accounts’ passwords.

For Perimeter E-Security managed security customers, we have implemented these protections:

  • Fortigate Antivirus is providing partial client-side protection with JS/Iframe signatures
  • Fortigate Web Content Filtering can block Unrated sites and all *.RU domains if requested
  • IDS Monitoring and 24/7 SaaS Security Monitoring benefits from SIEM correlations created to track this activity and 24/7 Security Analsyts to escalate alerts and assist with log analysis

Due to the complexity of this campaign, it is recommended that local desktop antivirus software be frequently updated. You should also use web browser plugins, such as NoScript, to block unauthorized scripts.


Five Years On, iOS Security Has Been a Huge Win for Customers

Written by Andrew Jaquith. Posted in Blog Post

Apple introduced the original iPhone in June 2007, a little more than five years ago. It’s appropriate at this point in time to ask whether Apple’s then-new, untested mobile platform has lived up to its promise as a secure platform. F-Secure’s Mikko Hypponen, one of the few consistently rational voices in the anti-virus vendor community, believes iOS has been good for customers from a security perspective. As he tweeted yesterday:

iPhone is 5 years old today. After 5 years, not a single serious malware case. It’s not just luck; we need to congratulate Apple on this.

On the opposite side of the argument is Sophos’ Josh Long. Although he concedes that the Apple’s App Store is “relatively safe,” he argues that Apple could do a better job vetting and patching, and that the risks of jailbreaking are still high:

Security researcher Charlie Miller has previously figured out how to break the App Store anti-malware model using a flaw in the iOS code signing enforcement mechanism, and there have been reports of developers working around other App Store restrictions with clever tricks; see the Security Now! episode 330 transcript and search for “vetting.”… The history of jailbreaking iPhones and iPads has provided plenty of evidence that smartphone users are being made to wait too long to get security updates for their devices.


How Vulnerable are Unprotected Servers in the Cloud? Part II

Written by Grace Zeng. Posted in Blog Post

By Grace Zeng and David Coffey

In Part I we described our experiment with 15 unprotected servers in the cloud under two configurations and showed the elapsed times of port scan, vulnerability probe and exploit. In this post, we would like to share the observations and insights we gained from this experiment and discuss several ways to protect your machines, whether they are running in the cloud or on-premise.


  1. Every machine on the Internet is scanned within minutes after connecting. It does not matter whether a machine connecting to the Internet opens ports or not — any machine will be scanned within several minutes. This is not surprising because attackers don’t know it a priori – they need a scan to figure out.
  2. More open ports means more vulnerability probes. The amount of elapsed time between the initial connection and the arrival of vulnerability probes depends on the specific services that are running. The more listening services a machine has, the sooner it will be probed, and the more risks it will be exposed to.
  3. More vulnerabilities means more exploits. It is rare that attackers send exploits blindly without first knowing that their targets are vulnerable. On the other hand, if unprotected machines have holes, chances are good that attackers will find them and attempt to exploit them. How long it takes depends on the vulnerabilities a machine has.
  4. Login attempts are more common than exploits. We observed that attempts to log in were much more frequent than vulnerability probes or exploits. On each machine, we captured dictionary attacks at ports 445 (SMB) and 3389 (RDP), attempting thousands of username/password combinations. Most attempts targeted accounts with administrator privileges. Weak or default passwords can be easily broken.
  5. Unknown exploits are rare. Even though our machines were otherwise unprotected, we saw few unknown exploits. This suggests that security products such as firewalls, IDS/IPS and AVs are likely to be effective in protecting computers from the most common attacks.

Recommendations for customers

Our experiment showed that the Internet is perilous. Attackers are constantly searching for targets. Although the Windows operating systems have become more secure, machines are still vulnerable to attacks. We do not recommend that customers follow our example — that is, putting unprotected servers into the cloud or directly onto the Internet.

To protect machines from attacks, customers should employ a multi-layered defense strategy. Appropriate defensive tactics fall into two categories: network-based and host-based. Network-based mechanisms include firewalls, IDS/IPS and anti-virus tools. (Note that in-cloud customers are not able to customize and deploy all network-based mechanisms, but do as much as you can. For instance, on Amazon EC2, you can easily configure inbound traffic rules on the management console for each machine.) Host-based methods include anti-virus software, host firewalls and host-based IDS/IPS (HIDS/HIPS) as well as security log management agents. Network-based defenses can secure your entire network perimeter and prevent threats from reaching computers inside the network, while host-based defenses safeguard individual machines from attacks. Customers can also limit the risk by taking action to reduce attack surfaces.

Network-based tactics


Firewalls are a vulnerable but important part of network-based defenses. Customers should:

  • Configure firewalls to deny all unwanted incoming traffic. As a result, attackers scanning the public-facing IP address will see most ports closed or filtered, and subsequent vulnerability probes and exploits will not be launched.
  • If some firewall ports must be open, restrict source and destination ranges. If your business requires you to accept incoming connections such as port 3389 (RDP), you should configure your firewall to restrict logins to users and IPs that are allowed to make such connections; connections from other sources will be denied.
  • If source restriction is not possible, consider rate limiting attack-prone traffic. For example, a common attack tactic is to attempt to brute-force logins on the target system. As a defensive tactic, you can implement rules that drop traffic from source IPs whenever the number of failed login attempts exceeds a threshold within a given time window. This allows externally facing machines to get a few failed logins but not an entire brute-force or dictionary attack. Similar rate-limiting rules can be set up to filter out targeted port scans and host sweeps as well.

Intrusion detection/prevention systems (IDS/IPS) and anti-virus (AV) tools

Although firewalls are generally effective in allowing legitimate traffic while blocking unwanted traffic, they work at a coarse level of granularity. They also have limited abilities to examine the content of the traffic. Customers should:

  • Install a network-based IDS/IPS. These provide more granular protection. IDS/IPS can inspect traffic to detect vulnerability probes and exploits by matching known attack patterns. These products also use heuristics to quickly pinpoint malicious communications and take necessary actions thereafter.
  • Incorporate network-based AV tools. IDS/IPS is communications centric, whereas AV tools provide visibility into files, programs and data transferred in the traffic in ways that IDS/IPS cannot. AV tools are especially capable of capturing packed and polymorphic malware in transmission.

Host-based tactics

In addition to network-based defenses, customers can add defenses on the host. Customers should:

  • Use AV software to prevent, detect and remove malware on host machines. These products are able to identify malware that propagates not only through network communications but also through channels such as USB drives.
  • Enable/Install a host firewall to allow or deny traffic that is transmitted from, or received by, particular programs or applications.
  • Install a host-based IDS/IPS (HIDS/HIPS) product on critical servers to provide full visibility into what is happening on the host — all system events happening in the memory, file system and registry. HIDS/HIPS also uses behavior-based rules to defend against unknown threats.
  • Consider utilizing log management agents to collect and monitor important system logs. Especially when HIDS/HIPS is absent, log management agents provide audit trails for further analysis and can send alerts in real time as incidents occur.

Attack surface reduction tactics

Besides the deployment of necessary defense mechanisms, customers can take additional, largely non-technical, steps to reduce the attack surfaces of Windows machines.

  • Always use strong passwords — either a combination of letters, numbers and symbols or an easily remembered but hard to guess long phrase.
  • Disable and/or uninstall unused services.
  • Restrict anonymous SMB logons.
  • If possible, change default ports such as RDP (3389) to less known ports.
  • Always keep Windows and installed software up-to-date — ideally, automatically.

To sum up, no matter whether a machine is in the cloud or on-premise, one single defensive tactic is insufficient to protect it from attacks. Customers should combine host-based and network-based defensive mechanisms as well as attack surface reduction tactics to create a multi-layered defense to protect your machines.

Andrew Jaquith and Richard S. Westmoreland contributed to this post.


How Vulnerable are Unprotected Servers in the Cloud? Part I

Written by Grace Zeng. Posted in Blog Post

By Grace Zeng and David Coffey

The Internet is a playground for opportunistic attackers. Right now, there are thousands of malware threats circulating around the Internet. Most computers today are protected by firewalls, IDS/IPS and anti-virus (AV) tools. But what happens when they do not have any protection? Previous experiments on “Time-to-Live-on-the-Network” and “Survival Time” of Windows machines were conducted quite a few years ago with test machines running old Windows operating systems. The “Four-Minute Windows Survival Time” claim in 2008 was especially criticized for using a Windows XP RTM or SP1 version in the test.

Since the time of these initial time-to-live studies, the Internet threat environment has become deadlier. Meanwhile, the Windows operating systems have become more secure. Because the state-of-the-art changes so quickly, we wanted to know how well an unprotected machine with a current operating system does in today’s threat environment. Left to its own devices, how soon will it be probed and attacked? We are particularly interested in testing unprotected machines hosted in the cloud because enterprises are increasingly turning to the cloud for various business purposes.

Experiment design

We ran our experiment with 15 machines in Amazon’s Elastic Computer Cloud (EC2) environment with two configuration profiles: “wide-open” and “out-of-the-box”. In the wide-open scenario, a machine opens all ports and emulates all possible services. This way the machine can attract as many malicious attempts as possible. In the out-of-the-box scenario, a machine runs only with default open ports and services. This scenario gives us a baseline of how many malicious attempts an unprotected machine might encounter.

Windows is by far the most popular operating system on the Internet. Its Server versions are generally exposed to more risks than Home/Professional versions. Our tests were carried out on the latest Windows Server 2008 R1 SP2 and R2 SP1. We disabled all firewall and anti-virus programs and configured the security policies so that Amazon would allow all incoming connections (TCP, UDP, ICMP) to those machines. We used Wireshark to capture packet-level traffic in real time.

To create the wide-open scenario, we installed a low-interactive honeypot named HoneyBot and disabled/changed several services to avoid interference. After the configuration was complete, we took a snapshot of the instance and created an AMI (Amazon Machine Image) for later use. We launched ten instances on EC2 using the same AMI and made sure that they were hosted in different geographical zones and were allocated different IP addresses.

For the out-of-the-box scenario, we made a clean install of Windows Server 2008 and didn’t install any programs other than Wireshark. By default, only ports 135 (RPC), 139 (NetBIOS), 445 (SMB) and 3389 (RDP) were open. We ran five such instances on EC2.

Scan, probe and exploit elapsed times

Malware infections follow a predictable pattern. Using a port scan, an attacker tests whether a port on a target machine is open. If so, a vulnerability probe gathers more information about a listening service, such as the version of the service – to identify vulnerabilities; and an exploit delivers malicious payloads to compromise the machine.

In  the wide-open scenario, after launching, on average it took about 23.4 minutes to see the first port scan, and 56.4 minutes to see the first vulnerability probe (the number for each server is shown in Figure 1).  Probes hit well-known ports such as 22 (SSH), 23 (Telnet), 25 (SMTP), 80 (HTTP), 445 (SMB), 1080 (SOCKS Proxy), 1433 (Microsoft SQL Server) and 3389 (RDP). With respect to exploit times, we observed that almost all first exploits were made within 24 hours, with the average time being 18.6 hours (Figure 2). We captured exploits on port 445 (SMB), 1434 (Microsoft SQL Monitor), 2967 (Symantec AV) and 12147 (Symantec Alert Management System 2). Almost all exploits during our month-long experiment were known threats. For example, the attack targeting port 12174 exploits a remote-code-execution vulnerability which was disclosed in 2009.

Figure 1. Scan and Probe Times for Wide-Open Servers (in minutes)

Figure 2. Exploit Times for Wide-Open Servers (in hours)

In the out-of-the-box scenario, it took an average of 13 minutes for the first port scan to arrive (Figure 3). Port scans hit ports such as 8080 (HTTP) and 1433 (MS SQL Server). The first vulnerability probe arrived within 3 hours on average (Figure 3); all probes were login attempts to Samba share (445) or via RDP (3389). We monitored the servers for a few weeks but didn’t see any exploits due to the limited number of open ports.

Figure 3. Scan and Probe Times for Out-of-the-Box Servers (in minutes)

Wrap up

Back to the question we asked in the beginning: On today’s Internet, how long does it take for an unprotected machine in the cloud to be probed and attacked? The short answer is: not very long.  What do we learn from the experiment? What can you do to beef up the defense of your machines? Go and check out Part II.

Andrew Jaquith and Richard S. Westmoreland contributed to this post.


New Research: Designing SMS-Based and P2P-Structured Mobile Botnets

Written by Grace Zeng. Posted in Blog Post

Early last week, I was attending the three-day WiSec’ 2012 (ACM Conference on Security and Privacy in Wireless and Mobile Networks) conference in Tucson, Arizona.  This conference used to focus primarily on wireless security topics, but this year it attracted quite a few papers on mobile security.  There was a whole session with five presentations on mobile device and application security – all of which were related to the Android platform. I was a presenter in this session, talking about my work titled “Design of SMS Commanded-and-Controlled and P2P-Structured Mobile Botnets.”

I have been researching botnet issues since 2007 when the Storm botnet was in its heyday.  Botnets have been primarily targeting personal computers in recent years. Not until 2009, did I start to think about the possibility of mobile botnets after seeing the growing popularity of the iPhone and Android-based phones. I felt that they would fall victim to attackers sooner or later because of the following factors:

  • Frequent downloading and sharing of third-party applications (esp. non-market applications) and user-generated contents
  • More processing power and memory
  • More personal and sensitive data stored
  • Multiple communication interfaces (SMS/MMS, Bluetooth, EDGE/3G/4G, WiFi) coupled with mobility
  • Lack of protection mechanisms

So I put myself in the attacker’s shoes to think ahead on how to construct a mobile botnet in an efficient and stealthy way. I designed a proof-of-concept mobile botnet that takes advantage of mobile services and stays resilient to disruption. Similar to PC-based botnets, a mobile botnet requires three key components: a vector to propagate the bot code; a channel to issue commands (a.k.a. command & control channel); and a topology to organize the botnet. Our bot code can be propagated through user-involved vectors such as hiding itself into popular game or system applications to entice users to download and install. My design primarily focuses on the command & control channel and the topology shown in the figure below. In this botnet, all C&C communications are transmitted via SMS messages and these messages are disguised as spam to be less noticeable. For example, the spam-like message shown in the figure actually encodes a command that asks the bot to send system information (SYS_info) to a server. To hide the identity of the botmaster, I adopted a P2P topology to allow the botmaster and bots to publish and search commands in a decentralized but structured fashion.


When I first started demonstrating the reality of mobile botnets in 2009, I received comments like “Mobile botnets are not realistic” and “Why would attackers bother to compromise smartphones? – there isn’t much a phone can do.” Over the past three years, we all have witnessed the evolution of mobile malware that has not only grown in number but also become sophisticated.

A few pieces of mobile malware in the wild have already demonstrated botnet-like behavior.  For example, in February this year, a malware application called RootSmart was discovered in third party Android markets in China and made headlines immediately. It was estimated to affect between 10,000 and 30,000 phones on any given day. Once started, RootSmart connects to a remote server to send information of the infected phone and fetches an exploit to root the phone. The infected phone is configured to send premium SMS messages and use other premium telephony services. Though the infected devices haven’t coordinately launched any large-scale attacks, potentially they can be instructed to do so because the attacker has full control of the rooted devices. Observing the advancement of mobile malware, people have realized that mobile botnets are becoming a real threat.  This emerging threat particularly concerns enterprises due to the exploding trend of employees using their mobile devices for company purposes –compromised smartphones that have access to privileged company resources can cause an enormous security problem. At the conference last week, the questions asked were: “Will mobile botnets be a more serious threat than PC-based botnets?” and “what countermeasures can we use?”

Indeed, my objective is not just to demonstrate that a mobile botnet can be stealthy, resilient and as sophisticated as a PC-based botnet, but to spur discussion on how to defend against this threat before it becomes serious. Although mobile botnets sound scary, unlike PC-based botnets that can infect your machines without your consent, mobile botnets cannot get to your phone without you taking some action. So, users, you are the first line of defense! Use caution when you download and install an application. (Android users, please pay attention to the permission list that is prompted to you and make good judgment. Does the application require strange permissions like sending/receiving SMS messages?) I believe an informed user can ward off a majority of mobile malware himself.

Unfortunately, many users have poor judgment. So automated detection solutions are still indispensable to securing mobile devices. Here are some options:

  • Mobile application certification is useful but has limitations.  Apple has a tight control over applications placed in its App Store, though it cannot limit what jail-broken iPhones do. The certification required on the Android Market is not difficult to get around – that’s why we have seen numerous disguised malware plaguing the Market. What is worse, there are many third-party Android application markets with malware circulating around. I think an additional protection such as an install-time certification is necessary. For the Android platform, an install-time certification can automatically analyze the application as well as its permission list and tell if it requires more permissions than it needs. In a proactive manner, it can alert the user or even prevent the application from installing if something suspicious is found.
  • Network-based detection should complement host-based detection.  Host-based detection solutions for mobile devices have been around for a while. Like their PC counterparts, such solutions may be disabled and uninstalled by malware. Since network-based detection is more resilient and has a good view of all devices’ traffic, it is better off working together with host-based detection to provide an additional layer of protection. But unlike in the PC world where a firewall and IDS/IPS can be placed at the entry point of a LAN, there are few vantage points in a mobile network. So a network-based detection solution has to scale well in order to protect a large number of mobile devices.

Interested readers: For more details, please refer to my WiSec paper here.




Three Articles Not to Read Today (file under: FUD and silliness)

Written by Andrew Jaquith. Posted in Blog Post

Here at the Perimeter STAR Team blog we try to keep level heads. Yes, information security is a dynamic field with lots of threat actors to worry about. Yes, it’s a fully buzzword-compliant field with lots of mumbo-jumbo. But no, despite what you might read, things are not all going to hell in a handbasket.

A big part of keeping our customers informed is knowing what to pay attention to, and what they should not worry as much about. We have, in the past, written some short “CTO’s reading list”/”5 articles you must read today” posts, describing news items of interest. Well, today I’m going to indulge my mischievous tendencies and do the opposite. So, here are three articles not to read, because they are silly, spread FUD or distract security managers from what they really need to be thinking about.

Don’t panic: Anonymous is not your biggest problem

The Wall Street Journal ran a story today, based on a Bit9 survey, that characterized Anonymous as security department’s biggest worry. As the article puts it, “some 61% of respondents to Bit9′s April report said they believed Anonymous or some other form of “hacktivist” attack, in which the perpetrators try to make an example of a company, would be the most likely assailant on their company computers.”

This is just silly. Anonymous is not your number one security problem. Anonymous is just one type of attacker companies need to worry about. As I described in my webinar, “The Hype and Reality of APTs,” (watch it for free!) there are at least three:

  1. the nation-states of China and Russia, sometimes and misleadingly called “advanced persistent threats,” seeking to steal industrial secrets;
  2. criminal gangs who want to steal and resell commoditized personal information about your customers, such as credit cards, personal health information, SSNs or other personally identifying information, and:
  3. anarchist groups such as Anonymous that have political agendas to embarrass or discredit governments and businesses.

Anonymous (#3) is just one type of threat actor. Not every company needs to worry about them. The key common factors in the target include: the target is powerful (government), affects the lives of many (any “establishment” organization: press, Wall St); engages in controversial practices or lines of business (biotech, fur, oil). If you aren’t in an industry or part of an institution that attracts controversy, Anonymous is definitely not your biggest problem. Stating otherwise is just plain fearmongering.

 Are you afraid of the Top Attacking Countries? Don’t worry, you don’t have to move.

Sophos released its periodic “Top Attacking Countries” Dirty Dozen spam report yesterday, with the tantalizing blog headline “India becomes the king of the spammers, stealing America’s crown.” In the article, we learn machines in Indian IP address space relay more of the world’s spam than those in any other country. As much as 9.3% of the world’s spam comes from machines whose IP address are in India. And the US? Well, clearly, we American citizens ought to feel left out because we were relegated to second place — the silver medal! (I feel hurt, don’t you?)

I’ve long been critical of this silly, silly report because it doesn’t help customers in the slightest. It’s just headline-grabbing linkbait that won’t help customers become more secure. For example, what should you do if you reside in India or the US and want to avoid spam? Move?  It’s unclear. From Sophos’ standpoint, this report is great because it takes no effort to put together any conclusions or blame anyone. It generates a lot of headlines and offends nobody.

Here’s what would be much more fun: who are the top relaying companies? Which ISPs do the worst job policing their networks for spammers? Which registrars allow the most spammers to create spam-related domains? Now that’s a report I’d like to see. You’ll never see it from Sophos, though, because actually fingering responsible parties might annoy their customers or prospects.

No, one-fifth of Mac customers are not infected

Sophos is on a roll today. Right on the heels of their fluffy “Top Attacking Countries” report, we see a post on their blog blaring that one-fifth of Macs are infected. This is based on 100,000 Mac customers that downloaded Sophos for OS X and discovered that, in fact, they are infected with something.

I am not surprised that 100,000 Mac customers are worried enough about their security that they felt they needed to download Sophos’ free antivirus software for OS X. Good for them. Nor am I surprised that a significant proportion of those worried customers were found to be infected. If you are feeling bad enough to go to the doctor, odds are that you’ve got a cold. Makes sense.

But it’s a step too far to suggest that this sample of 100,000 customers can be generalized to the Mac population as a whole. Generalizing in this way displays what statisticians call “selection bias.” It’s statistically dishonest, and misleading. And the headline doesn’t help: “1 in 5 Macs has malware on it. Does yours?”

I don’t mean to whitewash the relatively new and novel phenomenon of drive-by Mac malware. Research from Dr Web and Kaspersky has shown that several hundred thousand Mac customers have likely been hit by the Flashback Java-based backdoor malware. The number infected may be as much as 1% of the installed base — a significant percentage. That’s enough to be worrying anybody, and more than enough to remind every Mac customer of the importance of following sensible security precautions (turn off Java in the browser, turn off the “open ‘safe’ files option in Safari, use ClickToFlash to disable Flash, consider running an outbound firewall such as Little Snitch, run as a non-admin user, etc).

But there’s a huge gulf between a possible 1% infection for Flashback and the conclusion that 20% must be infected.

Do yourself a favor: try to tune out the siren sounds of Sophos ambulances and their yappy ambulance-chasing dogs speeding past your house. You will sleep better.


Mac Flashback Trojan Botnet Security Advisory

Written by Evan Keiser. Posted in Blog Post

On Monday, Apple released an urgent fix for a zero-day Mac Java flaw, reports Brian Krebs on KrebsOnSecurity. “The update, Java for OS X Lion 2012-001 and Java for Mac OS X 10.6 Update 7, sews up an extremely serious security vulnerability (CVE-2012-0507) that miscreants recently rolled into automated exploit kits designed to deploy malware to Windows users,” he reports.

Many Mac users believe that they don’t need to be concerned about malware attacks. However, reports have emerged that the Flashback Trojan is utilizing this same flaw to wreak havoc on more than half a million Macs worldwide — and counting. To make matters worse, the majority (56.6 percent) of infections are here in the United States.

According to Ars Technica’s Dan Goodin, Flashback is an increasingly sophisticated strain of malware that sniffs network traffic searching for user names and passwords. Previous versions of the Trojan prompted Mac users to enter their password before it would run, but the most recent strains don’t require a password. The strain is being spread via common Exploit Kits and its infection vector is utilizing a still unpatched zero day java exploit.

Although this issue should concern Apple customers, it’s important to note that nearly all Mac malware are Trojan horses. That is, the customer must take an active step to install harmful software, for example by installing little-known software found on shareware sites. If you spend time looking for “special codecs,” or for software that might be linked to other dodgy activities (for example, copyright protection cracking, BitTorrent, etc.) you might need to worry. Customers that always use Apple’s App Store, or obtain software from known-trustworthy vendors (Mozilla, Microsoft, Adobe, Twitter, etc.)  have essentially zero risk.

The Perimeter team is closely following this development and have put a correlation in place for all known command and control servers. Additionally, we strongly urge customers to investigate their Mac machines for evidence of the Trojan. We recommend visiting F-Secure, which has outlined a good set of instructions on how to identify an infected machine here. And of course, you should use Software Update to install the latest patch.