The post Recognizing Spam. . .Not As Easy As It Used To Be [Quiz] appeared first on Impermium.

Google’s roadmap calls for a much more aggressive two-factor authentication log-in scheme linked to a user’s cell phone or other Android device. Although the initial challenge to log in will be more rigorous, the idea is that it’s a one-time thing. Once people sign in on their device, that device can be used to authorize other services and other devices through near-field communication over a phishing-proof protocol.

This proposal represents a big step forward in account security, and if everything works out the way the authors envisage, we’d be in a much better place. As usual, there are a few key caveats, though:

1. Tying account security to a smartphone is certainly convenient and hugely secure: Forget having a complicated, 10-letter password, how about storing a 1,000-letter password on your smartphone? Yet while smartphones are nearly ubiquitous in many parts of the world, there still remain millions of Internet users who don’t have the latest and greatest, and those users still need an alternative way to log in. As with the “Account Recovery” vulnerability Google calls out, how can we avoid creating a new Achilles’s Heel that the bad guys will exploit?
2. Many of the requirements listed in the doc are interdependent. For example, you can’t give your smartphone the ability to log into every web site without dealing with the fact that tens of thousands of cell phone are stolen every year and 54 percent of cell phones are not password protected. Interdependency raises costs of integration, and we’re already dealing with a problem that many sites still don’t think of themselves as vulnerable. If we had a nickel for every SaaS web site that asked “why would someone want to hack into us”…
3. There are no silver bullets, and locking the doors sometimes isn’t enough to defeat a determined attacker. Security experts talk about “targets of choice” and “targets of chance.” These techniques are great at reducing the chances of an opportunistic criminal grabbing your account, but just like in the real world, if you have something valuable in your house, someone is going to try to steal it. You can replace it and change the locks. You can get more locks. You can invest in the most advanced locks on the market. The thieves will keep trying to find a way in. As long as you have something valuable inside, they have incentive to break through. And they have all the time in the world to do it.

Instead of relying on exclusively on locks–and waiting for the new locks to be installed—companies need to invest in proactive monitoring to complement the locks. Just like in the physical world, this virtual “police force” looks for suspicious patterns and attempts in the neighborhood and, by learning how the criminals behave across multiple locations, can stop them before they even reach your door.

By banding together, sharing information and using automated machine learning to profile how cyber-criminals behave online–where they go, what they do, who they talk to–we can help stop account takeovers across sites before they start.  Google and FIDO’s plan sets a new bar in locking down account security to protect user information. A proactive moderation ‘police force’ will further enhance these efforts, giving all sites across the web strong protection as new security protocols roll out and gain traction.

The post Google, FIDO and the Future of Account Security appeared first on Impermium.

Each day, early arrivers fire up the espresso machine and toast a bagel or grab a piece of fresh fruit before the daily standup conference call with their counterparts in the Bangalore office. The open work environment, with large windows, plenty of natural light, and whiteboard walls, encourages teamwork and discussion. For phone calls or small meetings, the newly decorated Library provides a quiet, softly lit space with soft, comfy seating.

A tasty lunch from Eat Club or Zero Cater is delivered three days a week. The team gets together in the Lounge for lively lunch discussions on the latest in movies or politics or hot sauces. Yes, hot sauces. There are no fewer than a dozen varieties available at any time. Everyone has a favorite, discovered during a recent hot sauce tasting at the office. After lunch, someone will likely recruit a group to gather around the Xbox for a skirmish with aliens in the other worlds of Skyrim or Halo.

Defending the internet requires plenty of energy, and Impermium keeps everyone well fueled. A variety of hearty and light snacks, representing all taste realms from sweet and salty to healthy and indulgent, are always available in the kitchen, along with beverages from the usual (Coke Zero and Red Bull) to the unique (Ginger Beer, discovered at another office tasting event). Each month, the whole company convenes for “Fourth Friday” where CEO Mark leads an all-hands meeting, and then everyone heads off for happy hour at a local pub.

Maybe you’ve seen some of the cybercrime fightin’ team wearing dark gray T-shirts displaying the symbol IM, for the element “Impermium”, of course. What appears to be atomic number 710 on these shirts actually represents Impermium’s date of incorporation in July 2010, when founders Mark Risher, Naveen Jamal, and Vish Ramarao first banded together to create the company that now provides Internet security for more than 300,000 sites around the world.

Whether scaling new heights at a local climbing gym or competing in a team bowling challenge or playing poker while munching on japaleño potato chips, life at Impermium is far from dull. We take our work seriously, the tide of malicious activity is rising, but even the most dedicated of crime fighters need to unwind sometimes. So if you’re looking for a new work challenge, you should check us out. Impermium is always looking for energetic, hands-on players, who enjoy the fast pace of a startup (and who can display a willingness to discuss the merits of hot sauces or ginger beer). Take a look at our jobs page. We’d love to hear from you!

The post Crime Fighters Wanted: A Peek Inside Impermium appeared first on Impermium.

Impermium’s client base grew steadily over the first year, increasing the amount of data processed on a daily basis by an order of magnitude every 3 months.  The Impermium solution easily scaled out from a handful of machines to several clusters of machines each performing data ingestion, processing, and analysis.  Although we handle most client requests in real time, providing a framework to analyze and comb through the data to find useful insights post-fact was important to tune and improve our realtime classifiers.  The data warehouse supported feedback processing, reputation building, and the ability to do complex time series analysis jobs to push ourselves higher on the precision/recall curve across our products.

Impermium’s Road to Scale
The fast uptake on business side was manageable because both the real time component and the batch analysis component were designed to handle large data loads.  But supporting functions such as transporting the data to our cluster and real time analysis of content data quickly became a pain point.

Initially, we investigated using either Scribe or Flume for data transportation.  Scribe had poor documentation, obscure build requirements, and was generally a pain to work with.   Flume looked promising but was buggy at the time (message size limits, reliability issues), and we didn’t feel comfortable running JVM on our event processing servers.  Scribe ended up working for us but not without some investment in digging through the codebase, hooking it up to write to HDFS and testing that it worked correctly under failure cases that we might encounter.  We have been very happy with it since, although revisiting Flume or Kafka (LinkedIn) is on our roadmap.

There came a point where unix command line tools such as grep and awk were not scaling for content.  Stemming, finding attacks with slightly varying payloads and just the responsiveness of exploratory tasks was suffering.  We decided to incorporate Solr into our stack to help get quick insights and troll through the data.  But as soon as we onboarded more content oriented clients, a single machine was not scaling well for us. Managing our own Solr shards in a cluster was not something we wanted to focus our attention on.  And so we migrated over to elasticsearch which provided a more scalable and self-balancing architecture that worked well.

Everyday, the pipeline processes tens of millions of users and builds models based on billions of events.  We use a combination of Hive, streaming, Java Mapreduce, and Elasticsearch to transform data, train classifiers, and index fields for ad-hoc analysis.  We also leverage redis and hbase to provide support for in-memory lookups of data and pub/sub capabilities for further processing.

Exploration and Analysis Tools
Once the data is transported to HDFS, we use a variety of tools to dig through it.  We also duplicate a part of the data on elasticsearch to leverage its realtime search capabilities to further understand the data.

Hive

• Quickest way to do ad hoc analysis on lots of data.  Allows complex queries in a few lines of HiveQL.  The majority of our production code currently resides in hive queries.
• Open source UDF, UDAF’s provide common aggregate functions.  We created a few custom UDF’s to help us extract features and prioritize data.

Dumbo/Streaming

• Dumbo’s translation into streaming is great because it abstracts away a lot of the cruft of streaming and allows the user to stay in conception “map” and “reduce” land.  A lot of our ad-hoc scripts are written in dumbo since it requires no overhead of creating tables as hive does, and because Python is very developer friendly.
• Streaming is good for testing precompiled binaries or programs that just need to leverage the computation scale of the cluster.

Java Mapreduce

• Necessary to ingest custom file formats without having an additional transcode step.  Provides glue to connect dependent clusters that require access to the data.
• Many 3rd party libraries are sometimes only available in Java.

Elasticsearch

• Ad-hoc data exploration
• Leverages lucene’s work on text processing

Lessons Learned

UTSL (or RTFS in some cases)
Learning to work with open source software stacks is a tricky business.  There can be a lack of documentation, outdated or outright incorrect documentation, or possibly undocumented “features”.  Compatibility between versions isn’t guaranteed and certain versions might be more stable than the recommended ones.  The guaranteed way to understand what is going on in a particular case is to “Use The Source, Luke” or sometimes “Read The F-ing Source” depending on how much it affects production and how close the sun is to being up.

Everyone is Different
Benchmarks provided by people selling a product and/or support either use biased data or biased use cases to highlight their own capabilities.  Blog posts / quora posts that compare a category of products are better, but only provide a starting point for your own benchmarks.  Every use case is different: read/write rates, amount of data stored, how data is accessed, even hardware configurations can all play a role.  This is not including how much your startup is willing to pay and how important a certain feature of a product is to the current roadmap.  All of these variables make each technology choice unique and potentially important to how the company plans to grow.

Conclusion
Impermium’s architecture is scalable, but not overly ambitious.  Although we started small and did not need to scale at the outset, we built the system so we would have options when it became necessary.  The stack we have today is well suited for the problems we currently are trying to solve.  However, the amount of data, type of data, type of analysis, algorithmic requirements, SLA requirements, etc, could all change in the future.  With this in mind, we constantly evaluate new technologies and stay focused on making our product stronger by having an architecture that allows us to iterate quickly when the time comes.

The post Built to Scale: How does Impermium process data? appeared first on Impermium.

The threat is real and getting more real every day. So why are these attacks becoming more prevalent? And what can we do to protect ourselves?

As major brands expand their reach online, attracting millions of followers, they become irresistible to criminals. By gaining access to just one account, they can get instant, real time access to an incredibly large audience. Remote hackers can operate from just about anywhere in the world and continue their deliberate, focused efforts to take over targeted accounts. Because it’s so difficult to catch these highly mobile villains, they have little reason to stop and great incentives to continue their efforts. So as the social web continues to saturate our lives, we can unfortunately expect these types of attacks to continue.

Conventional wisdom holds that much of the responsibility for account security rests with the user. Users must create a strong password and be vigilant for phishing scams. They must educate themselves on security risks and privacy concerns before giving their information to any site or service. But these measures are no longer enough–a determined hacker can circumvent even the strongest password created by the most savvy user.

Instead, service providers must make a sustained investment in defensive measures like proactive monitoring and risk-based authentication. Not only do the web sites have a better vantage point to detect suspicious behavior, but since these attacks are launched from a remote location, oftentimes none of the signals are even detectable from the legitimate user’s network.

Recently, many services have started to offer ‘two-factor authentication’ to protect their users. At each log in, a user receives a text message or code on their mobile phone or special-purpose device that they enter into the site to further verify their identity. This measure certainly enhances security, but also represents a significant usability trade off. You could put four deadbolts on your front door to secure your house, but it’s going to be a pain every time you go to the drugstore. Similarly, if you’re in a hurry to log into an online service, rooting around in your backpack for your smartphone can be a major inconvenience.

While two-factor authentication is an important and admirable step—and Impermium is partnered with TeleSign, one of the leading providers—determined hackers can still circumvent even two-factor measures by, for example, setting up a fake login page that tricks the user into entering both their password and their verification data.

We need a new approach to account security. Instead of relying solely on information users explicitly report, such as passwords and two-factor codes, sites need to look at big data across the Web. Just as in real life, virtual criminals act differently than legitimate users. They go to different places, talk to each other differently and move in different ways. By using automated machine learning to look broadly at different types of data across many different sites, we can identify patterns and trends that will allow us to weed out bad actors before they can gain a foothold on their target’s site. This approach will allow us to be proactive in stemming the tide of account takeovers instead of moving to secure or shut down accounts after the fact.

The world of the Internet, account security and online crime is still in its infancy. As it continues to grow, evolve and gain prominence in our lives, our efforts to protect ourselves must grow and evolve along with it. The criminals won’t stop and neither should we.

The post Stemming the Account Takeover Tide appeared first on Impermium.

While an army of Android-powered zombies has not yet arisen, a much more serious threat does already exist in the mobile realm: mobile impersonation. Because of the restrictive environment presented to mobile app developers—the “application sandbox” which limits what an app can access in an effort to stem the tide of mobile malware—software has a tough time differentiating between one phone and the next. Furthermore, each mobile web browser looks nearly identical to the next from the web server’s point of view, making it practically impossible to separate visitors. Perhaps most difficult of all, there is no surefire way for a server to know conclusively that traffic is truly coming from a mobile device versus a cleverly-disguised emulator.

These challenges combine to create an ideal environment for cyber criminals to impersonate a legitimate device, cloak their malicious activity in the guise of an innocent one, or point high-powered attack machines at weakly-defended mobile gateways. And each of these attacks can lead to the increasingly prevalent scourge of account takeover.

Security always involves a tradeoff with usability. Because web pages designed for mobile devices must work with tiny keyboards and limited screen space, designers often dial back their security requirements. Unfortunately, this presents a perfect opportunity for attackers. If they can successfully masquerade as a mobile device, they are presented with a less-challenging interface. Signs of these attacks are manifold.

Trusteer reported recently on criminals who use stolen account credentials from mobile devices knowing that while regular web sites often verify whether a browser has been seen before, mobile web sites often give the benefit of the doubt to new browsers. Similarly, because typing passwords on mobile keyboards is such a chore, many mobile applications grant long-lived sessions—keeping users logged in for months or longer—which presents opportunities for hackers to attack at leisure.

So what can we do to defend the increasingly mobile-accessible cloud from an increasingly mobile-aware adversary? Without the guarantee of a unique device identifier, sites worried about device impersonation must rely on broader, multi-dimensional sets of attributes to determine risk: who is interacting with the device, where are they coming from, and what behaviors are they exhibiting? Moreover, they must evaluate these attributes as sets, rather than one-by-one, to paint a nuanced picture of risk. For example, by looking at the sequence, capitalization, and configuration of less-common HTTP headers, Impermium has found “tells” that identify Android web browser versions that should not exist and which correlate strongly with suspicious behavior. In another example, the set of country + time of day + email domain have bubbled up as anomalous, giving valuable clues to rooting out and stopping bad actors.

Sites must also pay heed to mobile app validation, to avoid creating a “weaker link.” For many cloud services Impermium has analyzed, the server “assumes” that any traffic using the mobile application protocol is, ipso facto, a mobile app. Unfortunately, this line of thinking often leads to assumptions about the trustworthiness of that traffic, assuming, for example, that “nobody could make 1,000 password attempts from a tiny keyboard,” while missing the point that an abuser who gains access to that password entrypoint from a desktop machine could automate the attack in a matter of seconds. To guard against this, application developers must ensure that their internal APIs have the same risk assessment technology as their customer-facing ones. To the extent possible, app-to-server communication should also be signed, though by itself this cannot stop a determined attacker who already has access to the private key.

Mobile devices and cloud services are a marriage made in heaven, but to ensure the security of their customers, app and service developers must work to maintain—and ideally elevate—the level of security across the mobile environment. Rather than imposing inflexible usability burdens on end-users—I hate typing in strong passwords on my iPhone keyboard, too—sites must find ways to transparently perform real-time risk calculation in the background, using step-up authentication only when needed. This will help elevate security with a minimal sacrifice of usability. At Impermium, we have found that analyzing data horizontally—i.e. looking across the hundreds of thousands of sites we protect—has helped identify nascent patterns a single site or app might not notice. Additionally, usability designers must continue to innovate on graceful ways to limit malevolence without penalizing innocent users; it’s been a long time since the last Symposium on Usability for Privacy and Security. Mobile productivity apps have an important balance to strike to remain usable and secure. Whether they work with us or another provider or develop their solution in-house, mobile applications must plan for security from the get-go to ensure they protect and serve their customers.

The post Fighting ‘Mobile Malware’ appeared first on Impermium.

We care about User Generated Content (UGC). A lot. At Impermium, we employ patented machine learning algorithms to stop the bad guys from spreading spam, taking over accounts and exploiting the vulnerable. When discussing adversarial machine learning, the temptation is to focus on classifiers. However, one of the bad guys’ basic tricks is to throw a few rare Unicode characters into their malicious content, for example replacing the ‘a’ in Bank.com with the Unicode ‘å’ to construct a phishing link (i.e. Bånk.com). Since many programming languages still make assumptions about what type of characters to expect, if the front end encounters Unicode characters it may throw away parts of the data before the message reaches the classifier. If exploited by the criminals, this trick can allow malicious content to circumvent the classification phase. Because of this risk, at Impermium we emphasize flawless handling of Unicode data as a requirement for our front end.

This post focuses on the roles that the following play in our machine learning strategies and how we ensure that our system handles Unicode data smoothly:

• ASCII (American Standard Code for Information Exchange) and Unicode
• Encodings
• Terminals and terminal character encodings
• Programming languages such as Impermium’s language of choice, Python 2.x.

There are, of course, other elements that may come into play. Character sets like EBCDIC and others are out there, but for the purposes of this post we’ll pretend that they do not exist, like Indiana Jones and the Kingdom of the Crystal Skull or the new Star Wars movies. Fonts also play a role, but we will limit the discussion of fonts to this: if you (or your clients) do not have the requisite fonts installed, you will still not be able to ‘show’ your immaculately managed Unicode strings.

ASCII and Unicode

At base level, ASCII is a character encoding scheme—i.e. a way for computers to store and represent letters—initially developed to represent English text. The original ASCII was a 7-bit code that could represent several control characters, punctuation symbols, numbers, basic mathematical operators, and upper and lower case English letters; for example, the capital letter ‘A’ is represented by the number 65, and lower case ‘z’ is 122. ASCII was extended over time to use the ‘wasted’ one bit to represent additional characters, most notably ISO-8859-1 (a.k.a. “Latin 1”) which could represent the alphabets of several other European languages (e.g. adding the ‘á’, ‘ê’, and ‘£’ symbols). As programming continued to evolve and a broader set of computer users came online through the 1980s, it became clear that eight bits would never be sufficient to represent languages from across the broader world. Unicode emerged as a solution to this problem. Unicode assigns a unique code point, a single number, to each character it represents. The total number of Unicode code points is 1,112,064 and each code point can always be represented using four bytes.

Encodings

So things are simple right? Each Unicode character will be represented—i.e. encoded—using four bytes just like each character in ASCII was represented by one byte. One size shall again fit all! That is exactly what UTF-32 encoding does! Each code point is represented by 4 bytes. A Byte Order Marker (BOM) character U+FEFF can be used to indicate if the bytes representing a character are stored in little (big) endian format or the protocol may implicitly specify the format. The need for efficiency, however, shatters this happy picture. Since only twenty one bits are actually needed to store any Unicode character, and since a large majority of text is still in US-ASCII, using 32 bits for every character is wasteful. This need for more efficient representations resulted in the specification (and widespread use) of UTF-8 and UTF-16 encodings. UTF-8 encoding uses just one byte for US-ASCII data, two bytes for most European languages, and three bytes for most characters in common use today. Four bytes are only needed for some rare Asian characters, alphabets from historic scripts, and some mathematical symbols. UTF-16 uses at least two bytes to represent characters. The complete Unicode code point space is divided into seventeen planes of 16 bits. The first plane (the so-called basic multi-lingual plane) can encode US-ASCII and major European languages. Other planes (called supplementary planes) are encoded as pairs of 16-bit units called surrogate pairs. Both UTF-8 and UTF-16 are in widespread use today.

Python 2.x

At Impermium, Python 2 is our language of choice. It has two string types, ‘str’ and ‘unicode,’ both derived from basestring class. The ‘str’ string type is largely obsolete and there is rarely reason to use it in new code unless required for backwards compatibility. In fact, Python 3 only uses Unicode string type and phases out ‘str’ completely. Unlike the Unicode string type, ‘str’ is a wrapper for an 8-bit byte array and not just a sequence of ASCII characters. As a result, ‘str’ can hold arbitrary binary data.

With the above in mind, here are simple rules for working with character data in Python 2.x.

1. You must always know the encoding of the data that you receive.
2. Always work with the Unicode string type. When you read in the character data, convert it to Unicode type as soon as possible and always keep strings in your code as Unicode type. Strings declared in your code should begin with a ‘u’ prefix (e.g., u”Hello, World”).
3. When the character data is ready to be output, encode your character data into the agreed upon encoding at the last possible moment when it is ready to be outputted.

Finally, when you print data to the terminal, you must encode the data using the encoding for which the terminal is configured or results may be unpredictable.

The snippet of code below illustrates these rules. The task is to read in a UTF-16 encoded file and print it to a UTF-8 terminal.

#!/usr/bin/python
# -*- coding: utf-8 -*-

import sys
import codecs

fname = "utf-16_test.json"

sys.stdout = codecs.getwriter('utf-8')(sys.stdout, 'strict')

with codecs.open(fname, encoding='utf-16') as fh:
    for line in fh:
        print line.strip()

Following rule one, we specify the encodings for input (UTF-16) and output (UTF-8) up front when we create the file handles.

Following rule two, we then convert the lines in the file to Unicode as we read them in! So, in our code, we never keep the data as str type, explicitly, but rather perform all our operations over the Unicode string.

Finally, following rule 3, we encode the string in the output format at the last possible moment. Notably, we specify the encoding of the python source file to UTF-8 by specifying “# -*- coding: utf-8 -*-”. This encoding should be consistent with the settings in your editor. If your editor is set up to use UTF-16, you will see unexpected behavior such as improper characters displayed.

With the increasingly global nature of the Internet, programmers in all fields must plan ahead for proper character encodings. It is no longer sufficient to build only for the ASCII character set, nor can we blindly trust our programming languages to automatically handle everything for us. I hope this article provides you the background and details necessary to help ensure your programs are fully compliant with the full set of languages and characters in use across the Web.

Notes:

• Languages like Java (and Python 3!) have one internal string type. Java always uses UTF-16, while in Python 3, the internal representation actually depends on how your version of Python was compiled, but is usually UTF-16.
• You can use Python’s locale module to find out the encoding set for the terminals. If the second element in the pair returned by locale.getdefaultlocale() can display your data, you can then encode your data using this encoding.

The post Internationalization in Python 2 appeared first on Impermium.

Attackers

First, let’s look at different types of actors that Impermium sees directly attacking the sites we protect across the web. These actors seek to compromise and exploit web systems to gain access, steal personal information, propagate spam/malware and fraudulently get cash from consumers. The machines they use to perform these attacks are either hosts on bulletproof hosting sites that they proxy requests through, or compromised machines in a botnet that they rent.

• Account Creators
  • These attackers create massive numbers of fraudulent accounts on social, banking, and messaging sites which social network builders and account hackers later use when executing their attacks. They use bulk-created email addresses at popular consumer hosted email sites with randomly generated names and passwords to create legitimate looking registrations across the Internet. Those who wish to spread malware or spam across the social web later purchase these accounts in bulk.
• Social Network Builders
  • These attackers automatically perform user-actions that simulate human behavior and can make accounts look legitimate when inspected automatically or by a human. Sites put these measures into place in response to security systems, assigning a high risk to actions taken by an account with little to no history. These attackers create “ghost networks” of fake, but superficially believable, accounts. Typically, these accounts are later used for spam or malware campaigns, but have a higher value due to their “human-like” appearance.
• Account Attackers
  • Account attackers typically consist of commercial spam, fraud, or botnet operators who use fraudulent or compromised accounts to perform a variety of nefarious deeds. They most commonly spread advertising and malware links, gain personal information for future attacks, or perform fraudulent financial transactions. Some of these attackers are botnet operators focused on distributing malware to increase the size of the botnets or replace members that have been cleaned. A whole different type of attack focuses on distributing referral links to products and services in order to generate cash for the spammer.

Upstream Enablers

In order to execute attacks – compromise machines, launch distributed spam campaigns, request financial transactions, and grab credit card info – attackers need support. This support comes from both hardware and software including exploit creators, bulletproof hosting providers, and botnet operators.

• Exploit Creators
  • In our ontology, the exploit creators are often blackhats responsible for providing executable programs that infect both server and end-user machines. The software that they provide infects a computer and turns over control to a botnet operator.
• Bulletproof Hosting Providers
  • A bulletproof hosting provider makes servers available to customers for a short period of time and is very permissive about the traffic that originates from or goes to the server. This means that tracking back fraudulent actions to an IP often dead ends at an uncooperative hosting provider making it difficult to determine the original perpetrator of an act.
• Botnet Operators
  • A botnet operator infects and controls a large number of consumer machines without their owners’ knowledge. Attackers rent groups of these machines to perform denial-of-service attacks, spam attacks, mass registrations, etc. Because these connections originate from a legitimate consumer connection, it is often difficult to distinguish a legitimate action from an illegitimate one, especially using IP blacklisting techniques.

Downstream Financial Services

The ultimate goal for most attackers is to cash out financially. The following participants enable this goal by providing a way to get real money through illicit behavior. Isolating the fraudulent actors from the merely annoying ones presents a challenge to any attempt to remove a financial incentive for malicious behavior. Another challenge is that there is no single definition of what constitutes illegitimate behavior on the Internet and there will always be those who push the limits.

• Unscrupulous Banks
  • The credit card industry considers several banks based in Eastern Europe and Russia to be high-risk. This is largely due to the fact that they process a significant number of transactions paid with stolen credit cards or purchases of illegal goods. The paper “Click Trajectories: End-to-End Analysis of the Spam Value Chain” points out that only three banks provide the payment servicing for over 95% of spammed goods. These banks enable spammers to continue operating and could function as a natural bottleneck to stop the flow of money into the ecosystem.
• Referral Networks / Advertising Companies
  • Most companies are not picky about where and how they generate potential clients.. Often, this sort of “shotgun” approach to bringing in leads results in the product being spammed across social networks and lead generators participating in undesirable marketing approaches. Referral networks pay for interested traffic that drives sales on a merchant website. By giving a cash-out option to those who generate such traffic in a less than straightforward way, these referral networks are responsible for funding many of the current attackers.

What We Have Learned

Each actor involved in the social fraud ontology participates in the ecosystem in a distinct way. We know there are infrastructural actors of varying degrees of legitimacy that enable the attackers by providing either the resources they need to perform the attacks or the exit points that allow them to extract money from the system. By understanding how the bad guys operate, Impermium can more effectively target the bottlenecks with specific solutions that prevent fraud on sites we protect.

The post Closing the Loop on Account Compromise and Social Fraud appeared first on Impermium.

“Whoa, I just logged into my admin panel and found 10,000 new comments!” 

Typically, high numbers of page views and user interaction is a good thing. However, when you experience an explosion of comments in a short period of time, typically they turn out to be spam.  Has this ever happened to you? Did you ever wonder how spam attacks like these originate? At Impermium, we see many types of spam attacks – from small leaks to devastating tidal waves of spam.  While spammer behavior can sometimes be hard to detect, it’s easy to see the effect it has on your website, and is often very hard to stop.

Here I will discuss the four main types of spam attacks – Single-User, Distributed, Multi-platform Automated Distributed, and Botnet. Using data from real spam attacks, I will detail what a spammer account may look like, from the number of accounts to the degree of magnitude.

Single User Attack

Spammers utilize many different strategies when executing an attack; many operate the attack manually, and others automate their messages to maximize impact. In a single user attack, the spammer creates many accounts and jumps between them, submitting large bursts of spam comments. Large volumes is relative, because even the most fervent commenting spammers can only submit about 2-4 comments per minute; any more is simply physically difficult to do. Single user attacks are persistent and low-threat, but they can be hard to eliminate because once you ban one account, the user will re-populate with new accounts registered with new emails and logins.  And banning the IP address doesn’t help either – you don’t want to ban an entire IP due to one (really) bad user.

Distributed Attack

In a distributed spam attack, many automated accounts are created – likely using a blackhat program such as Xrumer – to send out one blast of spam messages on targeted social networks. Shortly after the spammer activity, the account goes silent.  These types of spammers are easy to identify. Because manual spammers can only submit a limited number of comments per hour, when we see a large volume of comments scattered across a wide range of articles (upwards of 100 articles with 50+ comment submissions each), we can easily identify them as automated accounts.

Because of the type of activity on these accounts, they are often blocked from use on certain platforms. Though this isn’t a problem for the attackers, as they simply create new accounts to use, blasting similar messages. 

Multi-Platform Automated Distributed Attack

Multi-platform distributed automated attacks (besides being a mouthful) harness the power of many accounts. Each account posts a consistent, low volume of messages per day and the combined impact achieves quite a high volume.  Many of these accounts never post more than 10 comments per day, making it difficult to identify as an aggressive attack.  However, with over 1000 accounts posting similar comments, it can add up quickly.  The graph only shows the first 20 accounts from this user, but try to imagine – there were over 7,000 comments during this month based on one common search term used in this spam campaign.

This is probably the most dangerous type of spam campaign, because the attackers have created a strategy that goes undetected by most website security systems. It also tests specific messages across multiple accounts and multiple platforms, testing the best entry points to distribute content across your network.

Botnet Attack

In a botnet attack, there is very little manual interaction from the spammer, who instead relies on distribution of spam from a server or cluster of compromised computers, submitting millions of randomized comments with specific spam links across the web. This graph only illustrates the first twenty sampled accounts for this attack, so it’s important to consider that there were about 1,000 separate user accounts working together across dozens of different platforms. Making this attack even more damaging, was that each message and each user was coming from a different IP location, which is a sign of a proxy setup and botnet attack. Altogether, the messages were bundled in distributions over a three-day period.  This is a rapidly accelerating attack that hits hard and fast before quickly disappearing.

If you have the right defenses in place, this attack can be dealt with by close monitoring and quickly adapting a few specific features to put in place instantly.  However, if you are not prepared, the botnet’s content can quickly take over your site.

It’s clear that spammers have become quite sophisticated, employing deep, strategic plans to execute their attacks. But no matter the type or severity of the attack, every spammer can be dealt with.  Each perpetrator leaves a fingerprint that may be attributed to either an http header, the duplication of content across multiple profiles, or through the links that are posted. Safeguarding your site against bad actors is important, as spam and malicious content is a real problem with measurable pains for website users and online companies, who experience losses in the form of revenue, maintenance costs, user attrition, and damage to brand reputation. You can’t stop spam attacks on your own, so trust a reliable source to identify and prevent attacks and malicious activity from showing up on your site.

The post The Four Types of Spam Attacks appeared first on Impermium.

Our team is comprised of incredible engineers and experienced executives whose professional talents are matched by diverse interests. On any given day, I am learning about machine-learning technology and behavioral modeling, as well as Halo 4, community gardening, and Scotch whisky. Plus, the team has a mostly healthy love for food, which means there’s always something interesting to eat. Take your pick from a cheese board, a sampling of everyone’s favorite hot sauces, or a firecracker bar that blends chocolate and Pop Rocks together.

The contrast could not be starker between Impermium and the Department of Defense, where I worked previously, yet both experiences are similarly inspiring. Every day, I am exhilarated to contribute to building something that enhances security online. I enjoy connecting with industry colleagues at events like the RSA Conference and collaborating with our business partners to make security more cost efficient. And, as a bonus, I am consistently energized and challenged by an exceptional team in the Impermium office.

Reminders about why I joined Impermium are never far from reach. News about compromised accounts and networks are becoming too commonplace. Earlier this month, Evernote thwarted intrusions into its networks and in a precautionary move, required its 50 million users to reset their passwords. And in the past month, Apple, Facebook, Microsoft, The New York Times, Twitter, and The Washington Post each disclosed network breaches. All of these headlines beg the question, what should companies do to increase their security online?

Cybersecurity challenges increasingly create hassles with everyday transactions. No one enjoys discovering that their account has been hacked. And, no one enjoys security that imposes more hoops to jump through at every transaction. 

With our new Invisible Gatekeeper product, I am helping customers decrease these hassles with security that’s easier for users and better for businesses. Bad guys are exploiting password weaknesses. And, companies want to assess how severe the problem is and deploy solutions to protect their users and data. It is rewarding to illuminate how our risk assessment technology can help.

In short, it’s been an awesome start to my new role. And we’re growing! If you are interested in joining Impermium, please check our website. We’re always looking to add more smart, energetic people to our team.

The post My First 30 Days at Impermium: Insights from Candace appeared first on Impermium.