Monthly Archives: April 2016

  • 0

Check Point Customer Success Video: Helvetia Insurance, vSEC for VMware NSX

Category : Check Point

For over 150 years, Helvetia has grown into a successful international insurance group with a wide range of services. Andreas Hagin, Head of Corporate Network & Unified Communication Engineering at Helvetia, discusses the importance of IT security and how Check Point vSEC meets the needs to support Helvetia’s software-defined data center strategy with VMware NSX.

  • 0

How Attackers Identify Targets for DDoS Attacks [video]

Category : Imperva

In this webinar Andrew Shoemaker, a DDoS simulation expert from NimbusDDOS, gives you a rare glimpse into how hackers find the weak points in your defenses and exploit them to level devastating DDoS attacks. You’ll see real world examples of the tactics and methods used to create tailored DDoS attacks that can bring down a targeted network or application, and learn how best to defend against them.

DDoS LIVE: Watch as a Security Expert Performs a Live DDoS Attack from Incapsula on Vimeo.

  • 0

FireEye Extends Information Sharing Network

Category : FireEye

FireEye is focused on countering the evolving threats facing public and private sector organizations around the globe. Whether through information sharing, force multiplication, advanced warning from cutting edge intelligence, advanced detection, security as a service, or prioritization and rapid response, our mission is to turn the tide on the adversary.

We believe that the security industry is in need of a revolution – moving away from reactionary, event based strategies towards a proactive, intelligence-led approach. It is this long-held belief that has driven our acquisitions of firms such as Mandiant, iSIGHT Partners and Invotas, informed our product development strategies, and given birth to the FireEye Information Sharing Network. A belief in the power of this approach has been at the core of FireEye since its inception. Our advanced detection platform is powered through rapid collection and ingestion of threat intelligence.

Over the next weeks and months, you will hear a lot from FireEye on our views for driving this intelligence-led approach…

  • We will outline on our support for the creation of Information Sharing and Analysis Organizations (ISAOs) inside the United States (as mandated in Executive Order 13691.) FireEye will provide expertise and advice to the ISAO Standards Organization and the broader security community.
  • We will engage in an open dialogue on the difference between information and cyber threat intelligence, a critically important discussion in the face of widespread market confusion.
  • We will explore our views on the roles of the public and private sectors in driving the intelligence-led approach to security.
  • We will outline best practices for consuming information shared by ISAOs and for operationalizing commercial threat intelligence across people, processes and technology.

Today, we are thrilled to announce the expansion of FireEye’s Information Sharing Network (FISN) – broadening from its existing base of 150 participant organizations to include many more potential partners around the globe. Cybersecurity firms, public and private sector organizations and independent researchers who are interested in becoming members are invited to apply by emailing us at

The FireEye Information Sharing Network has been in place since 2013, providing a platform for the daily sharing of malware samples and indicators of compromise to a wide variety of organizations including national CERTs, NGOs, law enforcement agencies, leading cybersecurity companies, major anti-virus vendors, independent security researchers and private sector firms. It was strengthened with the announcement of our Global Threat Intelligence™ sharing initiative in 2015, which allows FireEye customers to share anonymized FireEye intelligence with their partners, customers and trusted community members. Its creation follows a long line of contributions to the cybersecurity community by FireEye and the companies it has acquired. A great example is the OpenIOC standard and suite of free tools released to the community in 2011 by Mandiant. OpenIOC was designed to fill a void for organizations that want to share threat indicators both internally and externally in a machine-digestible format.

Currently, the FireEye Information Sharing Network facilitates the open sharing of hundreds of thousands of malware samples on a daily basis, provides an avenue for one-on-one sharing of information deemed more sensitive, and serves as a pathway for advanced notice of FireEye’s proprietary security research. The information shared is anonymized to exclude personally identifiable information or anything that could identify a victim company, and the information shared by FireEye adheres to the strict confidentiality obligations contained in our customer agreements.

The FireEye Information Sharing Network features four key elements:

  • Malware: Open sharing of hundreds of thousands of malware samples on a daily basis.
  • Sensitive Information: One-to-one sharing of information deemed more sensitive by contributing members.
  • Advanced Notice of Proprietary Research: Advanced copies of FireEye security research reports shared among member participants.
  • Sharing beyond FISN: FireEye and other member organizations occasionally share information and brief non-member organizations on emerging threats.

We are proud of FireEye’s pioneering position in information sharing and cyber threat intelligence. We are committed to the real-time exchange of information across the security community and among private and public sector organizations as demonstrated by our management of FISN, the OpenIOC standard and its tools, and participation in programs such as US-CERT’s Cyber Information Sharing and Collaboration Program (CISCP).

We have also recognized the distinction between sharing indicators of compromise and malware – which is largely historical, event driven data – and the delivery of forward leaning, contextually based cyber threat intelligence. The sharing of threat indicators and malware has value, but its value is ephemeral based on the ease with which adversaries can modify their use of malware and command and control infrastructure. To maximize its value, the speed with which this information is discovered, shared and ingested is vitally important, thus our focus on standards such as OpenIOC.

Meaningful cyber threat intelligence delivers a deeper view into the actions, intent, tools and tactics, techniques and procedures (TTPs) utilized by the adversary – all areas that are much more difficult for adversaries to change with speed. It also incorporates human analysis to apply context that cannot be found in raw information feeds.

We’ve invested heavily into developing capabilities in both arenas, and with the recent acquisition of iSIGHT Partners, we now offer the most robust and comprehensive cyber threat intelligence capabilities in market.

Through the open FireEye Information Sharing Network and our commercial cyber threat intelligence offerings, we are committed to driving an intelligence-led revolution in security that strengthens defensive postures for organizations across the globe.

  • 0

How Asymmetric Routing Can Screw up Security

Category : Gigamon

Hearing half a phone conversation is like trying to solve a riddle. For instance, you might hear this:

     Totally. Life in the Fast Lanes.
     Yes. 100 percent.
     You got it. It’s going to be epic.
     Don’t forget your plaid pants and the balloons. I’ve got the blindfold.

You’re left thinking your buddies have planned a lame bowling party for your birthday. But what’s really going on is this:

     You ready for Friday night?
     Totally. Life in the Fast Lanes.
     Huh? I’m confused. He hates bowling. Are you joking?
     Yes. 100 percent.
     Wait? Is he right in front of you?
     You got it. It’s going to be epic.
     Now I get it. Okay, we’ll see you Friday, backstage, Metallica for the big b-day surprise.
     Don’t forget your plaid pants and the balloons. I’ve got the blindfold.

Hearing only half a conversation is not only confusing and annoying, but it’s a lot of work. And, in a way, it’s a bit like what happens with asymmetric routing.

The Problem with Asymmetric Routing

Many companies, especially those with large networks, use asymmetric routing. The practice, which allows packets to leave via one route and return via another, makes sense from an efficiency and redundancy perspective; but not so much from a security one.

Picture an organization that has one router on the top floor of its corporate headquarters; another on the ground floor. The top floor router sends traffic out. The ground floor router receives it back. If an employee makes a connection to, the request goes out through the top floor router, into the data center, through Web proxies, and on to The return flow from, however, comes back through the ground floor router. In this scenario, it’s impossible for anomaly and intrusion detection tools to do their job because they are only seeing half a conversation.

Security teams could log into multiple security tools to attempt to pull together packet streams and stitch together conversations to see what happened. But, as with your buddy’s call, it’s laborious and, often, confounding. Even if security tools could see that half the flows were here, half were there, the amount of traffic (so much on networks today) begins to confuse them.

Striking the Right Balance with Asymmetric Routing

The GigaSECURE Security Delivery Platform (SDP) helps organizations maintain the benefits of asymmetric routing without compromising security.

Tapped into all the right places in the network, the GigaSECURE SDP sees all traffic (regardless of the routers it traverses) and reassembles asymmetric conversations into a single stream that can be fed to any security tool. What’s more, it enables organizations to use fewer security solutions. For example, instead of needing two DDoS protection devices (one for the top floor router and one for the bottom floor router), an organization could attach a single DDoS tool to GigaSECURE and be able to receive all clean network flows.

Get the whole conversation with GigaSECURE to solve the asymmetric routing security problem.

Otherwise, you could wind up being the guy who helps spend $14M to deploy a slew of malware detection and next-gen firewalls that can’t prevent breaches because they can’t see all the traffic. Or worse, the guy who shows up to a Metallica concert in your Livin’ on a Spare bowling shirt.


  • 0

Visibility The critical Layer To Complete Data Center Transformation

Category : Gigamon

Is your data center missing a critical layer—Visibility?

  • Tool proliferation with limited visibility
  • Tool oversubscription and scalability
  • TAP/SPAN port contention

Gigamon VisibilityAn intelligent network monitoring fabric is a critical component of any data center or network infrastructure investment. Traditional monitoring methods of SPAN/mirror ports or TAPs can oversubscribe the tools, deliver limited visibility, and are limited in number to meet the needs of multiple tools.


A traffic visibility layer for the standard reference Data Center architecture

Gigamon Benefits

  • Informed decisions based on real-time visibility
  • Eliminate contention among tools
  • Reduce CAPEX and OPEX

  • 0

CyberArk Launches C3 Alliance with Global Technology Partners

Category : Cyber-Ark

New Program Brings Together Enterprise Software, IT Security and Services Providers to Build on the Power of Privileged Account Security to Better Protect Customers from Cyber Threats

 CyberArk, the company that protects organizations from cyber attacks that have made their way inside the network perimeter, today announced the launch of the C3 Alliance. Together with CyberArk, C3 Alliance members have committed to incorporate privileged account security best practices into their own offerings, and can leverage CyberArk privileged account data to deliver more valuable insight and threat response to customers. Inaugural members include BMC Software, Duo Security, FireEye, ForeScout, Intel Security, LogRhythm, Qualys, Rapid7, SailPoint, SecureAuth, Symantec, Tenable Network Security, Tripwire and Varonis.

“Privileged account security has become increasingly critical, since compromised privileged account credentials are a common denominator of many modern attacks,” said Garrett Bekker, senior security analyst at 451 Research. “With certified integrations between CyberArk and alliance members’ products, the C3 Alliance should make it easier for customers to extend the power of privileged account security across their organization and enhance their overall security posture.”

C3 Alliance members represent enterprise software, infrastructure and security solutions, including security information and event management (SIEM), identity and access governance, asset and vulnerability discovery, security management and authentication services that benefit from tighter integration with CyberArk for securing privileged accounts and using privileged data to detect and respond to threats.

“CyberArk is the leader in privileged account security and is pleased to work with a strong and growing ecosystem of partners that understand the importance of protecting and monitoring privileged accounts in the enterprise,” said Adam Bosnian, executive vice president, global business development, CyberArk. “The C3 Alliance brings together key enterprise and security software companies to deliver integrated, tested solutions to better protect our shared customers.”

C3 Alliance members typically integrate with the CyberArk Privileged Account Security Solution to deliver value to customers in the areas of proactive protection, detection and response:

  • Proactive Protection – Through certified CyberArk integrations with hardware and software applications, including vulnerability and compliance management solutions, DevOps tools and discovery and orchestration software, customers benefit from knowing that the privileged accounts used to access their systems, as well as the general targets and critical applications accessed, are better secured and monitored.
  • Faster Detection – Identity and access governance, SIEM and security analytics platforms benefit from access to detailed privileged activity data and targeted analytics, as well as bi-directional communication to deliver improved, centralized, enterprise-wide monitoring and identification of critical security threats. Privileged activity data includes information such as who has access to what systems, why, and when certain actions were taken.
  • Intelligent Response – Analytics and response-focused members leverage privileged account activity information to help customers identify and respond to high-risk attacker activity in real time and carry out deeper forensics analysis and remediation activities.

Supporting C3 Alliance Member Quotes

“Our recent M-Trends report identified privileged account harvesting and abuse as the single most consistent attack vector witnessed during our engagements last year,” said Ed Barry, vice president, Cyber Security Coalition at FireEye. “We’re pleased to be part of the CyberArk-led C3 Alliance and through tight integration of our respective solutions we enable our customers to respond much more quickly to these sophisticated attacks.”

“The C3 Alliance fills a critical gap in the market by bringing vendors together to address privileged account vulnerabilities across the enterprise,” said Pedro Abreu, chief strategy officer, ForeScout. “ForeScout’s CounterACT requires administrative credentials for all of our customers’ network endpoints, servers, systems and devices. With the CyberArk integration, we can securely store and manage these credentials, ensuring our customers’ most privileged user accounts have around-the-clock protection.”

“As an inaugural partner in the C3 Alliance, SailPoint is embracing CyberArk’s initiative to apply strong, policy-based controls to privileged credentials throughout the enterprise,” said Joe Gottlieb, senior vice president of corporate development for SailPoint. “The integration of SailPoint IdentityIQ and the CyberArk Privileged Account Security Solution gives our customers a unified view and centralized control of all identities, all accounts and all privileges, enabling them to better assess risks and streamline operations.”

Additional Resources

View a collection of C3 Alliance member videos:

Download the CyberArk white paper: “The Hidden Risks of Commercial Off-the-Shelf (COTS) Applications Using Privileged Credentials”:

For more information about the C3 Alliance, visit:

For companies interested in joining the C3 Alliance, visit:

  • 0

Evolving Clouds. Adaptive Defense. This is Security. Integrated.

Category : McAfee

Blue Skies Ahead? The State of Cloud Adoption

Discover how more than 1,200 IT security professionals around the world are planning to secure their clouds. This report looks at their cloud adoption plans, their biggest challenges, and their investment priorities.

Blue Skies Ahead

  • 0

Is Your Key Management Appliance Actually FIPS Validated?

Category : HP Security

When your main job is to protect the proverbial “keys to the kingdom” for many enterprise-wide applications that encrypt data, it’s important to have confidence that your key management system enforces high-assurance, dependable security controls. Not only must your keys remain secured during the lifetime of your data, company’s also have to periodically demonstrate proof of that protection to auditors. That proof lies with your key manager. So ask yourself—can you trust your key management practices and procedures today? What assurance guarantees can you rely upon?

It may not seem like a big deal to the ordinary person, but security-conscious customers care a great deal about FIPS 140-2—the standard that determines security assurance level. Security vendors may tell you that their security appliances are FIPS validated, but ask them to prove it! You have the right to ask a security vendor to point you to their certificate or you can simply go look online to see if their key management appliance has been officially validated. I’ll show you where to look, a little further into the blog.

If you do ask a vendor if the products they are pushing are officially FIPS validated, you will likely find yourself asking questions like this…

  • The certificate you sent me is over a year old and is not applicable to the version you sold me, and it’s based on older software/firmware. You’ve come out with several security updates since then.
  • Oh wait, you don’t have a current valid certificate on the equipment you want me to buy?
  • What do you mean it’s in progress? How long is that going to take?
  • I didn’t realize you meant the validation is only based on some PCI card or a crypto library *inside* your appliance. That doesn’t sound like it includes a fully validated hardware boundary (i.e., the full appliance chassis) to protect the key database, logs, configurations, etc. inside.

Yep, that’s what we hear all the time from customers that have simply had enough and want the peace of mind they get from Hewlett Packard Enterprise. If you’re running sensitive government, financial, healthcare or other industry systems that require FIPS 140-2 compliance, you better be running them on systems that are actually current, covered and compliant. No one wants to be left in the lurch, running non-compliant solutions that do not meet the federal or industry requirements that you’re under a legal obligation to follow–especially when you were given misleading information from a vendor, or the smoke and mirrors of an incomplete solution.

A FIPS 140-2 evaluation is currently a requirement for the sale of products implementing cryptography within the US federal government for sensitive, but not confidential, data. FIPS 140-2 level 2 means the hardware appliance is tamper evident and utilizes role-based authentication. Yes, the hardware could be tampered with but you will know immediately that it has been compromised while the appliance remains locked in its rack and you can take appropriate action for recovery. Level 2 of the certification has basically become a baseline standard and a nonnegotiable item for many companies where a compromise of key data would be an issue. It is mandatory for US federal agencies that handle sensitive information but is becoming increasingly important in healthcare, legal, public safety and mobile operators that are now requiring the implementation of this standard. UK and Canadian government agencies are also incorporating the standard into their government encryption environments.

Hewlett Packard Enterprise sets the pace for security vendors when it comes to meeting or exceeding worldwide standards and best practices. FIPS is just one standard we stand behind. FIPS is an acronym for Federal Information Processing Standards. This is a set of computer security standards established by the US federal Department of Commerce’s National Institute of Standards and Technology (NIST). The Computer Security Division within NIST works with the Communications Security Establishment (CSE) of the Government of Canada to drive the Cryptographic Module Validation Program (CMVP). They review and verify the testing results of independent labs for vendor cryptographic modules wishing to obtain a FIPS 140-2 validation. Vendor affirmed does not equal vendor validated. FIPS Ready and Designed to FIPS does not mean it’s validated either. Besides keeping your key environment certified, equipment that is CMVP validated will help neutralize security weaknesses and interoperability problems between different vendor products. Vulnerabilities show up fast and running on systems that operate with older firmware are going to be hit first. Feel free to search this page and see if your security appliances have a current, viable validation—you might not find one:

Are you running any applications that still use SSL with firmware prior to 2015? It’s unlikely after Poodle, Shellshock, Heartbleed, etc. which made firmware upgrades in 2015 critical. Ask if your security vendor’s FIPS-validated software or firmware was developed prior to 2015!

Version 4.0 and 4.1 firmware on the HPE Enterprise Secure Key Manager (ESKM) appliance is fully FIPS 140-2 level 2 validated by NIST. If you’re running HPE ESKM 4.1 you can feel confident of better security assurance because you’ll be protected with the most current, viable solution on the market. When HPE releases updates or patches that have NOT yet gone through FIPS validation, you’ll know the “apple didn’t fall far from the tree” and you are choosing a more reliable update.

Ask us about our SNIA certification as well for HPE ESKM’s implementation of the Key Management Interoperability Protocol (KMIP) which is governed by the OASIS standards body. HPE ESKM was the first hardware vendor to be certified by SNIA for the KMIP standard for security solution interoperability.

  • 0

Blocking uploads of sensitive data to OneDrive

Category : Imperva

See how Imperva Skyfence protects sensitive data by blocking uploads of personally identifiable information (PII) to OneDrive

  • 0

RuMMS: The Latest Family of Android Malware Attacking Users in Russia Via SMS Phishing

Category : FireEye


Recently we observed an Android malware family being used to attack users in Russia. The malware samples were mainly distributed through a series of malicious subdomains registered under a legitimate domain belonging to a well-known shared hosting service provider in Russia. Because all the URLs used in this campaign have the form of hxxp://yyyyyyyy[.] (where represents the hosting provider’s domain), we named this malware family RuMMS.

To lure the victims to download the malware, threat actors use SMS phishing – sending a short SMS message containing a malicious URL to the potential victims. Unwary users who click the seemingly innocuous link will have their device infected with RuMMS malware. Figure 1 describes this infection process and the main behaviors of RuMMS.

Figure 1. Overview of the RuMMS campaign and behaviors

On April 3, 2016, we still observed new RuMMS samples emerging in the wild. The earliest identified sample, however, can be traced back to Jan. 18, 2016. Within this time period, we identified close to 300 samples belonging to this family (all sample hashes are listed in the Appendix).

After landing on the victim’s phone, the RuMMS apps will request device administrator privileges, remove their icons to hide themselves from users, and remain running in the background to perform a series of malicious behaviors. So far we have identified the following behaviors:

●      Sending device information to a remote command and control (C2) server.

●      Contacting the C2 server for instructions.

  • Sending SMS messages to financial institutions to query account balances.
  • Uploading any incoming SMS messages (including the balance inquiry results) to the remote C2 server.
  • Sending C2-specified SMS messages to phone numbers in the victim’s contacts.
  • Forward incoming phone calls to intercept voice-based two-factor authentication.

Each of these behaviors is under the control of the remote C2 server. In other words, the C2 server can specify the message contents to be sent, the time period in which to forward the voice call, and the recipients of outgoing messages. As part of our investigation into this malware, we emulated an infected Android device in order to communicate with the RuMMS C2 server. During one session, the C2 server commanded our emulated device to send four different SMS messages to four different phone numbers, all of which were associated with Russian financial institutions. At least three of the messages were intended to check a user’s account balance at the institution (we could not confirm the purpose of the fourth).Through additional research, we identified several forum posts where victims complained of funds (up to 600 rubles) were transferred out of their accounts after RuMMS infected their phones.

We do not know exactly how many people have been infected with RuMMS malware. However, our data suggests that there have been at least 2,729 infections between January 2016 and early April 2016, with a peak in March of more than 1,100 infections.

Smishing: The Major Way To Distribute RuMMS

We have not observed any instances of RuMMS on Google Play or other online app stores. Smishing (SMS phishing) is currently the primary way threat actors are distributing the malware. The process starts when an SMS phishing message arrives at a user’s phone. An example SMS message is shown in Figure 1. The message translates roughly to“ You got a photo in MMS format: hxxp://”

So far we identified seven different URLs being used to spread RuMMS in the wild. All of the URLs reference the file “mms.apk” and all use the domain “”, which belongs to a top five shared hosting platform in Russia (the domain itself has been obfuscated to anonymize the provider).

The threat actors registered at least seven subdomains through the hosting provider, each consisting of eight random-looking characters (asdfgjcr, cacama18, cacamadf, konkonq2, mmsmtsh5, riveroer, and sdfkjhl2.) As of this writing, no files were hosted at any of the links. The threat actors seem to have abandoned these URLs and might be looking into other ways to reach more victims.

Use of a shared hosting service to distribute malware is highly flexible and low cost for the threat actors. It is also much harder for network defenders or researchers to track a campaign where the infrastructure is a moving target. Many top providers in Russia offer cheap prices for their shared hosting services, and some even provide free 30-day trial periods. Threat actors can register subdomains through the hosting provider and use the provider’s services for a short-period campaign. A few days later they can cancel the trial and do not need to pay a penny. In addition, these out-of-the-box hosting services usually provide better infrastructure than the attackers could manage to construct (or compromise) themselves.

RuMMS Code Analysis

All RuMMS samples share the same behaviors, major parts of which are shown in Figure 1. However, the underlying code can be quite different in that various obfuscation mechanisms were adopted to evade detection by anti-virus tools. We used a sample app named “org.starsizew” with an MD5 of d8caad151e07025fdbf5f3c26e3ceaff to analyze RuMMS’s code.

Several of the main components of RuMMS are shown in Figure 2. The activity class “org.starsizew.MainActivity” executes when the app is started. It first starts another activity defined in “org.starsizew.Aa” to request device administrator privileges, and then calls the following API of “” (the Android package manager to remove its own icon on the home screen in order to conceal the existence of RuMMS from the user:

setComponentEnabledSetting(MainActivity.class, 2, 1)

At the same time, ”org.starsizew.MainActivity” will start the main service as defined in “org.starsizew.Tb”, and use a few mechanisms to keep the main service running continuously in the background. The class “org.starsizew.Ac” is designed for this purpose; its only task is to check if the main service is running, and restart the main service if the answer is no. The class “org.starsizew.Tb” also has a self-monitoring mechanism to restart itself when its own onDestroy API is triggered. Other than that, its major functionality is to collect private device information, upload it to a remote C2 server, and handle any commands as requested by the C2 server. All those functions are implemented in asynchronous tasks by “org.starsizew.i”.

Figure 2. Android Manifest File of RuMMS

The class “org.starsizew.Ma” is registered to intercept incoming SMS messages, the arrival of which will trigger the Android system to call its “onReceive” API. Its major functionality is also implemented through the call of the asynchronous task (“org.starsizew.i”), including uploading the incoming SMS messages to the remote C2 server and executing any commands as instructed by the remote attacker.

C2 Communication

The C2 communication includes two parts: sending information to the remote HTTP server and parsing the server’s response to execute any commands as instructed by the remote attackers. The functionality for these two parts is implemented by doInBackground and onPostExecute respectively, two API methods of “android.os.AsyncTask” as extended by class “org.starsizew.i”.

Figure 3. Method doInBackground: to send information to remote C2 server

As seen from the major code body of method doInBackground shown in Figure 3 (some of the original classes and methods are renamed for easier understanding), there are three calls to HttpPost with different contents as parameters. At line 5, local variable v4 specifies the first parameter url, which can be changed by the remote C2 server later. These URLs are all in the form of “http://$C2.$SERVER.$IP/api/?id=$NUM”. The second parameter is a constant string “POST”, and the third parameter is a series of key-value pairs to be sent, assembled at runtime. The value of the first item, whose key is “method” (line 7), indicates the type of the contents: install, info and sms.

The first type of content, starting with “method=install”, will be sent when the app is started for the first time, including the following device private information:

  • Victim identifier
  • Network operator
  • Device model
  • Device OS version
  • Phone number
  • Device identifier
  • App version
  • Country

Figure 4 is an example of this string as seen by the FireEye Mobile Threat Prevention platform.

Figure 4. Example HTTP post message

The second type of information will be sent periodically to indicate that the device is alive. It only has two parts, the method indicated by word “info” and the victim identifier. The third type of information will be sent when RuMMS intercepts any SMS messages, including the balance inquiry results when it contacts the SMS code of a particular financial service.

Method onPostExecute parses the response from the above HTTP session and executes the commands provided by the remote attacker. As seen from the code in Figure 5, the commands RuMMS supports right now include:

  • install_true: to modify app preference to indicate that the C2 server received the victim device’s status.
  • sms_send: to send C2-specified SMS messages to C2-specified recipients.
  • sms_grab: to upload periodically the SMS messages in the inbox to C2 server.
  • delivery: to deliver specified text to all victim’s contacts (SMS worming).
  • call_number: to forward phone calls to intercept voice based two-factor authentication.
  • new_url: to change the URL of the C2 server in the app preference.
  • ussd: to call a C2-specified phone number.

Figure 5. Method onPostExecute: to handle instructions from remote C2

Figure 6 shows an example response sent back from one C2 server. Note that inside this single response, there is one “install_true” command, one “sms_grab” command and four “sms_send” commands. With the four “sms_send” commands, the messages as specified in the key “text” will be sent immediately to the specified short numbers. Our analysis suggests that the four short numbers are associated with Russian financial institutions, presumably where a victim would be likely to have accounts.

Figure 6. Example Response in JSON format

In particular, short number “+7494” is associated with a payment service provider in Russia. The provider’s website described how the code 7494 can be used to provide a series of payment-related capabilities. For example, sending text “Balance” will trigger a response with the victim’s wallet balance. Sending text “confirm 1” will include proof of payment. Sending text “call on” will activate the USSD payment confirmation service.

During our investigation, we observed the C2 server sending multiple “balance” commands to different institutions, presumably to query the victim’s financial account balances. RuMMS can upload responses to the balance inquiries (received via SMS message) to the remote C2 server, which can send back additional commands to be sent from the victim to the provider’s payment service. These could include resetting the user’s PIN, enabling or disabling various alerts and confirmations, and confirming the user’s identity.

RuMMS Samples, C2, Hosting Sites, Infections and Timeline

In total we captured 297 RuMMS samples, all of which attempt to contact an initial C2 server that we extracted from the app package. Figure 7 lists the IP addresses of these C2 servers, the number of RuMMS apps that connect to each of them, and the example URL used as the first parameter of the HttpPost operation (used in the code of Figure 3). This indicates that multiple C2 servers were used in this campaign, but one ( was the most heavily used.

Figure 7. RuMMS samples and C2 servers

Figure 8 shows how these samples, C2 servers and hosting websites are related to each other, including when they were compiled or observed. In the quadrant, the smaller boxes in blue-gray represent particular apps in the RuMMS family, while the bigger boxes in deep-blue represent C2 servers used by some RuMMS apps. The dotted arrows represent the use of a particular C2 server by a specific app to send information and fetch instructions. In this figure we have 11 RuMMS samples, all of which were hosted on the website as shown in the “y” axis. The dates on the “x” axis show the dates when we first saw these apps in the wild. This figure demonstrates the following interesting information:

The time range when threat actors distributed RuMMS on those shared-hosting websites is from January 2016 to March 2016.

  • Threat actors used different websites to host different payloads at different times. This kind of “moving target” behavior made it harder to track their actions.
  • The same websites have hosted different RuMMS samples at different dates.
  • C2 servers are shared by multiple samples. This matches our observations of C2 servers as shown in Figure 7.

Figure 8. RuMMS samples, hosting sites, C2 servers from Jan. 2016 to Mar. 2016

We do not know exactly how many people have been infected with RuMMS malware; however, our data suggests that there are at least 2,729 infections with RuMMS samples from January 2016 to early April 2016.

Figure 9 shows the number of RuMMS infections recorded in the last four months. When we first observed the malware in January, we recorded 380 infections. In February, we recorded 767 infections. In March, it peaked at 1,169 infections. In April, at the time of writing this post, we recorded 413 RuMMS infections. Although the propagation trend seems to be slowing down a bit, the figure tells us that RuMMS malware is still alive in the wild. We continue to monitor its progress.


Figure 9. RuMMS infections from Jan. 2016 to Apr. 15, 2016


Smishing (SMS phishing) offers a unique vector to infect mobile users. The recent RuMMS campaign shows that Smishing is still a popular means for threat actors to distribute their malware. In addition, the use of shared-hosting providers adds flexibility to the threat actor’s campaign and makes it harder for defending parties to track these moving targets.

Fortunately, FireEye Mobile Threat Prevention platform can recognize the malicious SMS and networking behaviors used by these RuMMS samples, and help us quickly identify the threat. To protect yourself from these threats, FireEye suggests that users:

  • Take caution before clicking any links where you are not sure about the origin.
  • Don’t install apps outside the official app store.

To detect and defend against such attacks, we advise our customers to deploy our mobile security solution, FireEye MTP/MSM. This helps our clients gain visibility into threats in their user base, and also enables them to proactively hunt down devices that have been compromised. In addition, we advise our customers with NX appliances to ensure that Wi-Fi traffic is scanned by NX appliances to extend coverage to mobile devices.

Appendix: RuMMS Sample Hashes