1. A few months ago, Shape released Shift Semantics, the newest tool in the Shift family of ECMAScript tooling.

    The Shift Semantics library defines a structure for representing the behaviour of an ECMAScript program as well as a function for deriving one of these structures from a Shift AST.


    While ECMAScript has many syntactic features, not every one of them maps to a unique behaviour. For instance, all static member accesses (a.b) can be represented in terms of computed member accesses on strings (a['b']), and all for loops can be written in terms of while loops. Shift Semantics defines a data structure called an abstract semantic graph (ASG) which has a node for each individual operation that an ECMAScript interpreter would need to be able to interpret all ECMAScript programs. When an ASG is created, information about the original syntactic representation is lost. Only the important bit about what that program is supposed to do remains.

    Why is this useful?

    Many use cases for ECMAScript tooling do not involve knowledge of the original representation of the program. For instance, if one is compiling an ECMAScript program to another lower-level language, it is convenient to define a compilation once for all loops instead of repeating much of the same code for each looping construct in the language. This greatly reduces the number of structures you have to consider for your transformation/analysis and eliminates any need for code duplication.

    What does it look like?

    There are 52 ASG nodes. Many of them have an obvious meaning: Loop, MemberAccess, GlobalReference, LiteralNumber, etc. Others are not as obvious. Keys is an Object.keys analogue, used to represent the for-in behaviour of retrieiving enumerable keys of an object before looping over them. RequireObjectCoercible represents the internal spec operation of the same name. Halt explicitly indicates that the program has run to completion, though it’s also allowed to be used in other places within the graph if one desires.

    Update: If you’d like to see GraphViz visualisations, see the examples in Pull Request #8 or run the visualiser yourself on a program of your choosing.

    How do I use it?

    If you don’t already have a Shift AST for your program, you will need to use the parser to create one:

    import com.shapesecurity.shift.parser.Parser;
    String js = "f(0);";
    // if you have a script
    Script script = Parser.parseScript(js);
    // if you have a module
    Module module = Parser.parseModule(js);

    Once you have your Shift AST, pass it to the Explicator:

    import com.shapesecurity.shift.semantics.Explicator;
    Semantics semantics = Explicator.deriveSemantics(program);

    The Semantics object’s fields, including the ASG, can be accessed directly. One can also define a reducer, in the same way a reducer is defined over a Shift AST: subclassing the ReconstructingReducer. Note that our ASG reducers have not yet been open-sourced, but will be soon.


    Currently, WithStatements and direct calls to eval are explicated into Halt nodes. There’s no reason that these cannot be supported, but they were not part of the initial effort. Similarly, not all of ECMAScript 2015 and beyond is supported. We will be adding support for newer ECMAScript features piece by piece as development continues.


    Thanks to Shape engineer Kevin Gibbons for figuring out all the hard problems during the design of the ASG.

  2. The mission of the Web Application Security Working Group, part of the Security Activity, is to develop security and policy mechanisms to improve the security of Web Applications, and enable secure cross-origin communication.

    If you work with websites, you are probably already familiar with the web features that the WebAppSec WG has recently introduced. But not many web developers (or even web security specialists) feel comfortable reading or referencing the specifications for these features.

    I typically hear one of two things when I mention WebAppSec WG web features:

    1. Specifications are hard to read. I’d rather read up on this topic at [some other website].
    2. This feature does not really cover my use-case. I’ll just find a workaround.

    Specifications are not always the best source if you are looking to get an introduction to a feature, but once you are familiar with it, the specification should be the first place you go when looking for a reference or clarification. And if you feel the language of the specification can be better or that more examples are needed, go ahead and propose the change!

    To cover the second complaint, I’d like to detail out our experience contributing a feature to a WebAppSec WG specification. I hope to clarify the process and debunk the myth that your opinion is going to be unheard or that you can’t, as an individual, make a meaningful contribution to a web feature used by millions.


    Content Security Policy is a WebAppSec WG standard that allows a website author to, among other things, declare the list of endpoints with which a web page is expecting to communicate. Another great WebAppSec WG standard, SRI, allows a website author to ensure that the resources received by their web page (like scripts, images, and stylesheets) have the expected content. Together, these web features significantly reduce the risk that an attacker can substitute web page resources for their own malicious resources.

    I helped standardise and implement require-sri-for, a new CSP directive that mandates SRI integrity metadata to be present before requesting any subresource of a given type.

    Currently, SRI works with resources referenced by script and link HTML elements. Also, the Request interface of the Fetch API allows to specify the expected integrity metadata. For example, Content-Security-Policy: require-sri-for script style; extends the expectations and forbids pulling in any resources of a given type without integrity metadata.

    Contributing to a WebAppSec WG Specification

    Unlike some other working groups, there is no formal process on how to start contributing to W3C’s Web Application Security Working Group specifications, and it might look scary. It is actually not, and usually flows in the following order:

    1. A feature idea forms in somebody’s head enough to be expressed as a paragraph of text.
    2. A paragraph or two is proposed either in WebAppSec’s public mailing list or in the Github Issues section of the relevant specification. Ideally, examples, algorithms and corner-cases are included.
    3. After some discussion, which can sometimes take quite a while, the proposal starts to be formalised as a patch to the specification.
    4. The specification strategy is debated, wording details are finalised, and the patch lands in the specification.
    5. Browser vendors implement the feature.
    6. Websites start using the feature.

    Anyone can participate in any phase of feature development, and I’ll go over the require-sri-for development timeline to highlight major phases and show how we participated in the process.

    Implementing require-sri-for

    1. Development started in an issue on the WebAppSec GitHub repo opened back in April 2014 by Devdatta Akhawe. He wonders how one might describe a desire to require SRI metadata, e.g. the integrity hash, be present for all subresources of a given type.

    2. Much time passes. SRI is supported by Chrome and Firefox. Github is among first big websites to use it in the wild.

    3. A year later, Github folks raise the same question that Dev did on the public-webappsec mailing list, with an addition of having an actual use case: they intended to have an integrity attribute on every script they load, but days later after deplyoing the SRI feature, determined that they had missed one script file.

    4. Neil from Github Security starts writing up a paragraph in the CSP specification to cover a feature that would enforce integrity attribute on scripts and styles. Lots of discussion irons out the details that were not covered in the earlier email thread.

    5. I pick up the PR and move it to the SRI specification GitHub repo. 65 comments later, it lands in the SRI spec v2.

    6. Frederik Braun patches Firefox Nightly with require-sri-for implementation.

    7. I submit a PR to Chromium with basic implementation. 85 comments later, it evolves into a new Chrome platform feature and lands with plans to be released in Chrome 54.


    Specification development is happening on Github, and there are many great specifications that you should be looking at:

    We Are Hiring!

    If you reached here, there is a chance that Web Platform Expert position looks interesting to you.

  3. Shape Security is proud to announce the release of SuperPack, a language-agnostic schemaless binary data serialisation format.

    First of all, what does it mean to be schemaless?

    Data serialisation formats like JSON or MessagePack encode values in a way that the structure of those values (schema) can be determined by simply observing the encoded value. These formats, like SuperPack, are said to be “schemaless”.

    In contrast, a schema-driven serialisation format such as Protocol Buffers makes use of ahead-of-time knowledge of the schema to pack the encoded values into one exteremely efficent byte sequence free of any schema markers. Schema-driven encodings have some obvious downsides. The schema must remain fixed (ignoring versioning), and if the encoding party is not also the decoding party, the schema must be shared among them and kept in sync.

    Choose the right tool for the job. Usually, it is better to choose a schema-driven format if it is both possible and convenient. For other occasions, we have a variety of schemaless encodings.

    What separates it from the others?

    In short, SuperPack payloads are very compact without losing the ability to represent any type of data you desire.


    The major differentiator between SuperPack and JSON or bencode is that it is extensible. Almost everyone has had to deal with JSON and its very limited set of data types. When you try to JSON serialise a JS undefined value, a regular expression, a date, a typed array, or countless other more exotic data types through JSON, your JSON encoder will either give you an error or give you an encoding that will not decode back to the input value. You will never have that problem with SuperPack.

    SuperPack doesn’t have a very rich set of built-in data types. Instead, it is extensible. Say we wanted to encode/decode (aka transcode) regular expressions, a data type that is not natively supported by SuperPack. This is all you have to do:

      // extension point: 0 through 127
      // detect values which require this custom serialisation
      x => x instanceof RegExp,
      // serialiser: return an intermediate value which will be encoded instead
      r => [r.pattern, r.flags],
      // deserialiser: from the intermediate value, reconstruct the original value
      ([pattern, flags]) => RegExp(pattern, flags),

    And if we want to transcode TypedArrays:

      a => [a[Symbol.toStringTag], a.buffer],
      ([ctor, buffer]) => new self[ctor](buffer),


    The philosophy behind SuperPack is that, even if you cannot predict your data’s schema in advance, the data likely has structures or values that are repeated many times in a single payload. Also, some values are just very common and should have efficient representations.

    Numbers between -15 and 63 (inclusive) are a single byte; so are booleans, null, undefined, empty arrays, empty maps, and empty strings. Strings which don’t contain a null (\0) character can avoid storing their length by using a C-style null terminator. Boolean-valued arrays and maps use a single bit per value.

    When an encoder sees multiple strings with the same value, it will store them in a lookup table, and each reference will only be an additional two bytes. Note that this string deduplication optimisation could have been taken further to allow deduplication of arbitrary structures, but that would allow encoders to create circular references, which is something we’d like to avoid.

    When an encoder sees multiple maps with the same set of keys, it can make an optional optimisation that is reminiscent of the schema-directed encoding approach but with the schema included in the payload. Instead of storing the key names once for each map, it can use what we call a “repeated keyset optimisation” to refer back to the object shape and encode its values as a super-efficient contiguous byte sequence.

    The downside of this compactness is that, unlike JSON, YAML, or edn, SuperPack payloads are not human-readable.


    After surveying existing data serialisation formats, we knew we could design one that would be better suited to our particular use case. And our use case is not so rare as to make SuperPack only useful to us; it is very much a general purpose serialisation format. If you want to create very small payloads for arbitrary data of an unknown schema in an environment without access to a lossless data compression algorithm, SuperPack is for you. If you want to see a more direct comparison to similar formats, see the comparison table in the specification.

    I’m sold. How do I use it?

    As of now, we have an open-source JavaScript implementation of SuperPack.

    $ npm install --save superpack

  4. Tens of millions of people are out exploring the new world of Pokémon Go. It turns out that many of those users are not people at all, but automated agents, or bots. Game-playing bots are not a new phenomenon, but Pokémon Go offers some new use cases for bots. These bots have started interfering with everyone’s fun by overwhelming Pokémon Go servers with automated traffic. Pokémon Go is a perfect case study in how automated attacks and defenses work on mobile APIs. At Shape we deal with these types of attacks every day, so we thought we would take a closer look at what happened with the Pokémon Go API attacks.

    Pokémon Go API Attack

    Niantic recently published a blog post detailing the problems bots were creating through the generation of automated traffic, which actually hindered their Latin America launch. The chart included in the post depicts a significant spatial query traffic drop since Niantic rolled out countermeasures for the automation at 1pm PT 08/03. The automated traffic appears to have been about twice that of the traffic from real human players. No wonder Pokémon Go servers were heavily overloaded in recent weeks.

    Figure 1. Spatial query traffic dropped more than 50% since Niantic started to block scrapers. Source: Niantic blog post

    Getting to Know The Pokémon Bots

    There are two types of Pokémon bots. The first type of bot automates regular gameplay and is a common offender on other gaming apps, automating activities such as walking around and catching Pokémon. Examples of such bots include MyGoBot and PokemonGo-Bot. But Pokémon Go has inspired the development of a new type of bot, called a Tracker or Mapper, which provides the location of Pokémon. These bots power Pokémon Go mapping services such as Pokevision and Go Radar.

    How a Pokémon Go Bot Works

    A mobile API bot is a program that mimics communication between a mobile app and its backend servers—in this case servers from Niantic. The bot simply tells the servers what actions are taken and consumes the server’s response.

    Figure 2 shows a screenshot of a Pokémon Go map which marks nearby Pokémon within a 3-footstep range of a given location. To achieve this, the bot makers usually follow these steps:

    1. Reverse-engineer the communication protocol between the mobile app and the backend server. The bot maker plays the game, captures the communications between the app and its server, and deciphers the protocol format.
    2. Write a program to make series of “legitimate” requests to backend servers to take actions. In this case, getting locations of nearby Pokémon is a single request with a targeted GPS coordinate, without the real walk to the physical location. The challenge to the bot is to bypass a server’s detection and look like a real human.
    3. Provide related features such as integration with Google Maps, or include the bot’s own mapping functionality for the user.

    Figure 2. Screenshot of a Pokémon Go map

    Mobile App Cracks and Defenses

    Using Pokémon Go app as an example, let’s examine how a mobile app is cracked by reverse engineering to reveal its secrets. Since attackers mainly exploited Pokémon Go’s Android app, let’s focus on Android app cracks and defenses.

    Reverse-Engineering the Protocol

    The Pokémon Go app and the backend servers communicate using ProtoBuf over SSL. ProtoBuf defines the data format transferred on the network. For example, here is an excerpt of the ProtoBuf definition for player stats:

    message PlayerStats {
      int32 level = 1;
      int64 experience = 2;
      int64 prev_level_xp = 3;
      int64 next_level_xp = 4;
      float km_walked = 5;
      int32 pokemons_encountered = 6;
      int32 unique_pokedex_entries = 7;

    Pokémon Go was reverse-engineered and published online by POGOProtos within only two weeks. How did this happen so quickly? Initially, Niantic didn’t use certificate pinning.

    Certificate pinning is a common approach used against Man-in-the-Middle attacks. In short, a mobile app only trusts server certificates which are embedded in the app itself. Without certificate pinning protection, an attacker can easily set up a proxy such as Mitmproxy or Fiddler, and install the certificate crafted by the attacker to her phone. Next she can configure her phone to route traffic through the proxy and sniff the traffic between the Pokémon Go app and the Niantic servers. There is actually a Pokémon Go-specific proxy tool that facilitates this called pokemon-go-mitm.

    On July 31, Niantic made a big change on both its server and its Pokémon Go app. Pokémon Go 0.31.0 was released with certificate pinning protection. Unfortunately, the cat was out of the bag and the communication protocol was already publicly available on GitHub. In addition, implementing certificate pinning correctly is not always easy. In the later sections, we will cover some techniques commonly used by attackers to bypass certificate pinning.

    APK Static Analysis

    The Android application package (APK) is the package file format used by Android to install mobile apps. Android apps are primarily written in Java, and the Java code is compiled into dex format and built into an apk file. In addition, Android apps may also call shared libraries which are written in native code (Android NDK).

    Dex files are known to be easily disassembled into SMALI languages, using tools such as Baksmali. Then tools such as dex2jar and jd-gui further decompile the dex file into Java code, which is easy to read. Using these techniques, attackers decompiled the Pokémon Go Android app (version 0.29.0 and 0.31.0) into Java code. The example code shown below implements certificate pinning from the com.nianticlabs.nia.network.NianticTrustManager class.

    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
      synchronized (this.callbackLock) {
        nativeCheckServerTrusted(chain, authType);

    When application source code is exposed, reverse engineering becomes a no-brainer. Pokemon Go Xposed used less than 100 lines of Java code to fool the Pokémon Go app into believing the certificate from the MITMProxy was the authentic certificate from Niantic.

    How did Pokemon Go Xposed achieve this? Quite easily. The tool simply hooks to the call of the function checkServerTrusted mentioned in the above code snippet. The hook changes the first parameter of the function, chain, to the value of Niantic’s certificate. This means that no matter what unauthorized certificate the proxy uses, the Pokémon Go app is tricked into trusting the certificate.

    There are many tools that can help make disassembly and static analysis by attackers more difficult. ProGuard and DexGuard are tools that apply obfuscation to Java code and dex files. Obfuscation makes the code difficult to read, even in decompiled form. Another approach is to use Android packers to encrypt the original classes.dex file of Android apps. The encrypted dex file is decrypted in memory at runtime, making static analysis extremely hard, if not impossible, for most attackers. Using a native library is another way to significantly increase the difficulty to reverse-engineer the app.

    Reverse-Engineering the Native Library

    The most interesting cat-and-mouse game between the pokemongodev hackers and Niantic was around the field named “Unknown6”, which was contained in the signature sent in the map request to get nearby Pokémon at a location. “Unknown6” is one of the unidentified fields in the reverse-engineered protobuf. Initially, it wouldn’t matter what value Unknown6 was given; Niantic servers just accepted it. Starting at 1pm PT on 08/03, all Pokémon Go bots suddenly could not find any Pokémon, which eventually resulted in the significant query drop in Figure 1.

    The hackers then noticed the importance of the “Unknown6” field in the protocol, and initially suspected Unknown6 to be some kind of digest or HMAC to validate the integrity of the request. This triggered tremendous interest from the pokemongodev community and an “Unknown6” team was quickly formed to attempt to crack the mysterious field. The Discord channel went private due to the wide interest from coders and non-programmers, but a live update channel kept everybody updated on the progress of the cracking effort. After 3 days and 5 hours, in the afternoon of 08/06, the Unknown6 team claimed victory, releasing an updated Pokémon Go API that was once again able to retrieve nearby Pokémon.

    While the technical writeup of the hack details has yet to be released, many relevant tools and technologies were mentioned on the forums and the live update. IDA-Pro from Hex-Rays is a professional tool that is able to disassemble the ARM code of a native library, and the new Hex-Rays decompiler can decompile a binary code file into a C-style format. These tools allow attackers to perform dynamic analysis, debugging the mobile app and its libraries at run time. Of course, even with such powerful tools, reverse-engineering a binary program is still extremely challenging. Without any intentional obfuscation, the disassembled or decompiled code is already hard to understand, and the code size is often huge. As an illustration of the complex and unpredictable work required, the live update channel and a subsequent interview described how the encryption function of “Unknown6” was identified within hours but the team spent an extensive amount of additional time analyzing another field named “Unknown22”, which turned out to be unrelated to Unknown6.

    As a result, obfuscation still has many practical benefits for protecting native libraries. A high level of obfuscation in a binary may increase the difficulty of reverse-engineering by orders of magnitude. However, as illustrated by the many successful cracks of serial codes for Windows and Windows applications, motivated mobile crackers are often successful.

    Server Side Protection

    Server-side defenses work in a completely different way than client-side defenses. Here are some of the techniques used in the context of protecting Pokémon Go’s mobile API.

    Rate limiting

    Rate limiting is a common approach to try to stop, or at least slow down, automated traffic. In the early days, Pokémon scanners were able to send tens of requests per second, scan tens of cells, and find every Pokémon.

    On 07/31, Niantic added rate limiting protections. If one account sent multiple map requests within ~5 seconds, Niantic’s servers would only accept the first request and drop the rest. Attackers reacted to these rate limits by: a) Adding a delay (5 seconds) between map requests from their scanning programs b) Using multiple accounts and multiple threads to bypass the rate limit

    In the case of Pokémon Go, the use of rate-limiting just opened another battleground for automated attacks: automated account creation. They quickly discovered that while rate limiting is a fine basic technique to control automation from overly aggressive scrapers or novice attackers, it does not prevent advanced adversaries from getting automated requests through.

    IP Blocking

    Blocking IPs is a traditional technique used by standard network firewalls or Web Application Firewalls (WAFs) to drop requests from suspicious IPs. There are many databases that track IP reputation and firewalls and WAFs can retrieve such intelligence periodically.

    In general, IP-based blocking is risky and ineffective. Blindly blocking an IP with a large volume of traffic may end up blocking the NAT of a university or corporation. Meanwhile, many Pokémon bots or scanners may use residential dynamic IP addresses. These IPs are shared by the customers of the ISPs, so banning an IP for a long time may block legitimate players.

    Hosting services such as Amazon Web Services (AWS) and Digital Ocean are also sources for attackers to get virtual machines as well as fresh IPs. When attackers use stolen credit cards, they can even obtain these resources for free. However, legitimate users will never use hosting services to browse the web or play games, so blocking IPs from hosting services is a safe defense and is commonly used on server side. Niantic may decide to ban IPs from AWS according to this forum post.

    Behavior Analysis

    Behavior analysis is usually the last line of defense against advanced attackers that are able to bypass other defenses. Bots have very different behaviors compared to humans. For example, a real person cannot play the game 24x7, or catch 5 Pokémon in one second. While behavioral analysis sounds a promising approach, building an accurate detection system to handle the huge data volume like Pokémon Go isn’t an easy task.

    Niantic just implemented a soft ban on cheaters who use GPS spoofing to “teleport” (i.e., suddenly moving at an impossibly fast speed). It was probably a “soft ban” because of false positives; families share accounts and GPS readings can be inaccurate, making some legitimate use cases seem like bots.

    On around Aug 12 2016, Niantic posted a note on its website, and outlined that violation of its terms of service may result in a permanent ban on a Pokémon Go account. Multiple ban rules targeting bots were also disclosed unofficially. For example, the Pokemon over-catch rule bans accounts when they catch over a thousand Pokemon in a single day. In addition Niantic encourages legitimate players to report cheaters or inappropriate players.

    In our experience, behavioral modeling-based detection can be extremely effective but is often technically or economically infeasible to build in-house. As Niantic commented in their blog post, “dealing with this issue also has opportunity cost. Developers have to spend time controlling this problem vs. building new features.” The bigger issue is that building technology to defend against dedicated, technically-savvy adversaries armed with botnets and other tools designed to bypass regular defenses, requires many highly specialized skillsets and a tremendous development effort.

    The Game Isn’t Over

    As Pokémon Go continues to be loved by players, the game between bot makers and Niantic will also continue. Defending against automated traffic represents a challenge not only for gaming but for all industries. Similar attack and defense activities are taking place across banking, airline, and retailer apps where the stakes are orders of magnitude higher than losing a few Snorlaxes. Bots and related attack tools aren’t fun and games for companies when their customers and users cannot access services because of unwanted automated traffic.

  5. Note: this post contains excerpts from a more detailed research note on Sentry MBA that the Shape Security research team has created for the security research community. If you are a security researcher and would like to receive a copy of this note, please email the authors at xinran@shapesecurity.com and nwokedi@shapesecurity.com.

    Credential stuffing is an attack that tests stolen credentials against the authentication mechanisms on websites and mobile application API servers, to discover instances of password reuse across those applications, and enable large-scale account takeovers. It is one of the most common attacks on popular web and mobile applications today and is capable of essentially breaching sites that do not have what are considered to be traditional security vulnerabilities. Instead, through automation, the task of hijacking accounts on any popular site is reduced to a question of economics: the attacker is virtually guaranteed to be able to hijack a certain number of accounts per unit of effort.

    In order to bypass traditional security controls, like IP rate limits, reputation lists, blacklists, and other forms of IP-based analysis, attackers utilize large sets of proxies and botnets. In order to bypass CAPTCHA and other controls designed to impede automated interaction with user interfaces, attackers use Optical Character Recognition (OCR) software and other complementary mechanisms to read and solve those challenges the way that a human user would.

    These services can be tied together to enable any number of automated attack types in economical ways. These economics become particularly cost-effective for cybercriminals when additional management tools are created for the purpose of facilitating specific attack types that combine all of these approaches. Over the past several years, many such tools have emerged that make sophisticated, compound automated attacks simple and efficient to execute by a wide variety of cybercriminals.

    In the case of credential stuffing, the most commonly used standalone management tool we have observed enabling attacks is called Sentry MBA. We have been observing Sentry MBA attacks across the Shape network, which includes the websites and mobile applications of some of the world’s largest companies, for some time.

    Here is a screenshot of the main interface of the tool, which is a standalone Windows application:

    The key inputs for a Sentry MBA attack are:

    • A config file, which helps Sentry MBA navigate the unique characteristics of the site being targeted; the URL for the targeted website’s login page, for example, is specified in the config file
    • A proxy file is a list of IP addresses (usually compromised endpoints and botnets) to route traffic through, so that the set of login attempts appears to be coming from a large variety of sources (resembling organic traffic) rather than from a single attacker
    • A combo list is a database of username/password pairs to be tested against the target site; these lists are typically obtained from breaches on other websites, and sold on underground forums, as well as available on public sites like Pastebin

    Sentry MBA has a number of additional features to assist the attacker further, including built-in OCR capabilities for bypassing CAPTCHA challenges and functionality to spoof various browser characteristics, such as the User Agent and Referer strings.

    A Sentry MBA config file contains, among other items, the URL for a website’s login page, field markers to help navigate form elements, and rules for valid password constructions. A number of forums offer a wide variety of working configurations for various websites. Here is a screenshot from one such forum:

    Once the attacker has a basic working configuration, Sentry MBA offers tools to optimize and test the attack against the live target website. For example, the tool can be configured to recognize certain keywords associated with a website’s responses to successful and unsuccessful authentication attempts.

    Proxy lists allow the attacker to bypass IP-based security controls. It is common across many attacks for over 60% of the IP addresses used to be new every day, and the total number of IPs can often go into the tens of thousands. As a result, blacklists can’t be updated quickly enough to be effective, and Sentry MBA can be tuned to ensure that no individual IP sends too many requests, which also prevents rate limiting from being effective.

    Finally, combo lists provide the raw materials for the attack. Across the Shape network, we have found that most combo lists have a 1% to 2% success rate, meaning that if an attacker purchases a list from a breach on site A (or a combination of site breaches) and then uses Sentry MBA (or another credential stuffing tool) with that list to attack site B, 1% to 2% of the usernames and passwords from site A will work on site B.

    In other words, if an attacker has a combo list of 1 million credentials, they may be able to hijack in the neighborhood of 10,000 accounts on any popular website using Sentry MBA with relative ease. Based on our own research and that of others in the security industry, there are hundreds of millions of unique credentials for sale in underground markets, a figure which is growing rapidly as more sites are breached.

    Once a cybercriminal has taken over accounts on their target website or mobile application API service, monetization strategies can take many forms, depending on the business model of the breached application. In fact, that part of the kill chain can be handed off to another group entirely. In the case of bank accounts or stored value card systems, for example, a bundle of breached accounts can itself be sold on underground forums, based on the estimated average value stored in the accounts.

    Have you been targeted?

    There are a number of ways to detect Sentry MBA attacks. Here are two low-effort mechanisms to determine if you have been targeted by a Sentry MBA attacker. The first is to search the web and the second is to look for the default User Agent strings that comes with Sentry MBA.

    Searching the web

    If your organization is a sufficiently high-profile target, you may be able to find criminals offering Sentry MBA configs for your website and mobile applications on various forums. Googling “sentry mba X”, where X corresponds to a name of your organization or web property is a good starting place. In this process, it’s critical that in addition to searching the Shallow Web, you also find ways to search the Deep Web. If you are unfamiliar with searching the Deep Web, you should consider consulting experienced open source intelligence analysts.

    Sentry MBA default User Agent strings

    As Dan Ariely has highlighted, humans tend to use defaults. Attackers are no different and we regularly see proof of this across the Shape network.

    By default, Sentry MBA uses the following five User Agent strings:

    1. Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
    2. Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
    3. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2009060215 Firefox/3.0.11
    4. Mozilla/5.0 (Windows; U; Windows NT 5.1; en) AppleWebKit/522.11.3 (KHTML, like Gecko) Version/3.0 Safari/522.11.3
    5. Opera/9.80 (Windows NT 6.0; U; en) Presto/2.2.0 Version/10.00

    If you find these User Agent strings in your web logs, you should also be able to find some characteristics of credential stuffing. The OWASP Automated Threat handbook notes that you should observe a high authentication failure rate when a credential stuffing attack is taking place. The term “high” is left to interpretation, but it’s fair to say that any authentication failure rate that is multiple standard deviations beyond the mean for your website qualifies as “high.”

    If you decide to blacklist these User Agent strings, you should recognize that they can be changed to bypass such a control. Before you take any action, we recommend you consider the associated game theory.


    The rise of Sentry MBA illustrates how automation enables cybercriminals to achieve unprecedented efficiency, efficacy and scale. The script kiddies have grown up and now have access to powerful attack frameworks which rival the complexity of the programming stacks used to create legitimate applications.

    There are many automated attack tools, including other credential stuffing frameworks, that vastly exceed Sentry MBA in sophistication. However, this serves to illustrate the real security challenge: the fact that Sentry MBA is so effective on so many major websites and mobile application API services today highlights the need for significantly more advanced application defense mechanisms.