Rogue Mobile App Events

Rogue Mobile App Events

Rogue Mobile App events are available to External Threats customers subscribed to the Mobile Threats module. They alert customers to mobile applications violating their configured mobile policy, including unapproved versions or download locations of mobile apps published by their organization, third party developed apps impersonating their the brand, and/or malicious mobile applications containing malware targeting users of their organization's mobile applications. 

When a new relevant app is found, a Rogue Mobile App event is created in the workspace which can be viewed in the events dashboard and events list inside the RiskIQ web application, in an email alert, and/or via the events API.

For a general introduction to events and other parts of the RiskIQ system, please see RiskIQ Platform Architecture

Outlined below are tips on:

  1. How to read and interpret the information presented in a Rogue Mobile App event (field definitions)
  2. Suggested best practices for Rogue Mobile App event management, including user workflow, and tagging
  3. How it works: Mobile Threats system workflow overview 

Example: a Rogue Mobile App Event created for an app published in the Apple App Store

Reading Rogue Mobile App Events - Field Definitions

Event List Item

This is how Rogue Mobile App events are represented in the Events section of the RiskIQ web application. Clicking on a list item brings up details for the event and user-initiated workflow actions.

  • Thumbnail screenshot  from the app posting that generated the event.
  • Event-Type: what kind of event it is (e.g. Rogue Mobile App).
  • Name: the title of the app as listed in the store.
  • Platform: the operating system for which the application is written (represented as an icon with hover-over text)
  • Status: current status of the event.
  • Created: date the event was created
  • Updated: date of the last entry in the event history
  • Developer: the developer name of the app as listed in the store.
  • App Store: the name of the app store in which the app is posted.
  • Active: whether or not the app is currently available within the store.
  • Store-Type: The category of store (based on how users access and download apps from the store, e.g. "Secondary")
  • Tags (if applied by users--not pictured below)

Event Header

At the top of each event's details is a header containing workflow actions. See Event User Actions for information on using these options.

Summary Tab

The Summary page provides a screenshot of the app and other information for assessing the event and deciding how to act on it. The Summary tab is organized into multiple sections:

APP

  • ID: unique identifier for this app in the RiskIQ Mobile DB (useful for sharing references to an app or event).
  • Name: title of the app.
  • Platform: operating system for which the app is built, e.g. Android, iOS, etc./li>
  • URL: link to view the app posting on the store.
  • Official ID: unique identifier for the app used by mobile devices (package name).
  • Category: category the app is placed under within the store. Note: different stores have different categorization systems and labels.
  • Access Type: app download is free or paid.
  • Ratings: number of times app has been rated/reviewed in the store.
  • Downloads: number of times app has been downloaded in the store.
  • Description: app description provided in the store posting. (Click to expand if it is more than 5 lines long or to Translate if it's not in English)

STORE

  • Store: name of the store/website providing the app.
  • Store Type: based on the download-type: official, secondary, affiliate, or hybrid (hovering over this field provides the definition for that type.)
  • Store Country: country in which the app store is based.

DEVELOPER

  • Developer: developer of the app listed in the store posting.
  • Contact Email: contact email provided for the organization publishing the app.
  • Contact URL: contact URL provided for the organization publishing the app.

PERMISSIONS

  • Permissions requested by the app (click to expand if there are more than 5; this section only visible if permission details are available). 

URLS

  • URLs used in the app (click to expand if there are more than 5; this section only visible if URL details are available)

HISTORY

  • Timeline of changes made to the event with the date, time, and name of the user who took each action, including:
    • Status changes 
    • Emails sent (with recipients)
    • Notes added
    • Tags added/removed

Versions Tab (If Applicable)

If the store provides the app file for direct download, this section tracks the different MD5s and versions of the same app official ID found within the same store (at the same posting URL). Users may also upload a new version manually.

Files Tab (If Applicable)

If the store provides the app file for direct download, this section allows you search the contents of the app binary for code strings and file types (currently available for Android apps / APK files only)

Classify Tab

This section details what about the page was flagged by the RiskIQ system in relation to your business logic. 

Classifiers score the characteristics of mobile apps seen by virtual users and determine whether or not an app should create an event according to the logic described in the policy. Each classifier used in event analysis is listed here with the number of hits, it's total score, and the highlighted page content that created the score per each available field that the classifier is targeted to.

The Re-Classify button re-scores apps on-demand using the information from the most recent time the app was checked if you have made changes to the classifiers used in Rogue Mobile App events since the most recent inspection of the app.

The page layout of app postings and terminology can be slightly different across each app store website, but they share the following common features that are extracted and parsed by RiskIQ on each posting in order to fuel analysis of mobile threats related to your brands.

Logos Tab (If Applicable)

If brand-related logos or images were detected within the app posting / store page and/or in the files of the app, then this section displays the found image, the similarity score to the official images used for comparison, and the ID and official images themselves.

Blacklist Tab (If Applicable)

If this app contains a blacklisted resource, then this tab shows additional information on why an app is blacklisted, including which AV vendors / reputational sources flagged it, and for what content.

Enforcement Tab

If this event has been enforced, then this tab shows additional information about any enforcement actions this event has been involved in, such as the date, the user who initiated the action, the recipients of the request, and the full text of the sent message.


Managing Rogue Mobile App Events - User Review Decision Workflow and Tagging Best Practices

The flow chart below describes a decision tree encompassing best practices for handling and enforcing rogue mobile app events. 

  • Green represents steps taken automatically by the RiskIQ system
  • Pink represents steps taken by a human user
  • Blue represents a status and/or tag label

Standard Tag Set

  1. Undetermined
  2. Legitimate App
  3. Unauthorized Official App
  4. Rogue App
  5. Acceptable Use
  6. Other

Mobile Threats System Overview

Detection

RiskIQ detects Mobile Threats based on our searching of hundreds of app stores. We run scheduled searches of each store using brand and other keywords to find relevant results. The frequency of these searches varies somewhat by store and other factors, but typically, a brand-related keyword will be searched in each store every few days. 

For each app result discovered, RiskIQ parses out key details of the posting, including the title, description, developer name, or other details provided by the store, as well as automatically downloading the binary using any download links provided in the post. Once the file is downloaded, we automatically decompile and analyze it to evaluate the app permissions, and check for malicious files or URLs, and search for any policy-related content (e.g. logos inside the app that not present in the posting page, or calls to an organization's API inside the app).

In addition to our regular searching of known app stores, we also supplement with opportunistic coverage of "feral apps", or any mobile binaries that the RiskIQ crawlers find outside of dedicated app store sites--for example, in drive-by-download malware attacks, or other sources. Whenever such a file is encountered anywhere by RiskIQ, we add it to our mobile app database to analyze in the same manner for malware or policy hits related to Mobile Threats customers.

Mobile apps are considered active as long as the URL where the app is posted is still accessible and the app details / file trigger the configured policy logic in the workspace. Some stores special custom inactivation logic if they display custom 404 pages or have other idiosyncratic behavior indicating that an app has been removed other than simply making the post URL inaccessible (ex. redirecting to the home page of the site). Different versions of the same app posted in the same location are treated as an update to  single event (multiple versions seen over time can be viewed in the versions tab of the event), rather than 2 separate events. If the files are posted at different URLs, they constitute separate events.

System Overview

The following diagram follows a  Rogue Mobile App event through the RiskIQ system from a virtual user first encountering an app through an app store search, to the analysis of the app, and through the event monitoring, including enforcement procedures if applicable, to resolution, and post-resolution monitoring. 

  • Green represents steps taken automatically by the RiskIQ system
  • Pink represents steps taken by a human user
  • Blue represents a status and/or tag label

If you are a RiskIQ admin user looking for step-by-step instructions on creating/modifying Rogue Mobile App classifiers, policies, or projects refer to Setting Up Rogue Mobile App Events.

Monitoring and Auto-Resolution

  • Some Rogue Mobile App events are monitored daily (e.g. iTunes), while most are monitored every 4-10 days according to store size, priority, and traffic level.
  • Apps in Mobile Search are updated far less frequently (monthly or quarterly) if there are not active events associated to them.
  • Rogue App Events move to resolved upon the first inactive check, and back to tenacious upon any future active check.