Threat-Events™, In-App Threat Intelligence in Kotlin Apps

Last updated November 28, 2024 by Appdome

This knowledge base article shows you how easy it is to use Appdome Threat-Events™ to get in-app threat intelligence in Kotlin Apps and control the user experience in your Kotlin Apps when mobile attacks occur.

What are Threat-Events?

Appdome Threat-Events is a powerful threat-intelligence framework for Android & iOS apps, which is comprised of three elements: (1) a Threat-Event, (2) the data from each Threat-Event, and (3) the Threat-Score™.

With Threat-Events, mobile developers can register, listen to, and consume real-time attack and threat data from Appdome’s mobile app security, anti-fraud, mobile anti-bot, and other protections within their mobile applications. This allows them to (1) ensure that mobile application workflows are aware of attacks and threats, (2) customize business logic and user experience based on the user’s risk profile and/or each attack or threat presented, and (3) pass the threat data to other systems of record such as app servers, mobile fraud analysis systems, SIEMs, and other data collection points.

The purpose of Threat-Events is to enable Android and iOS applications to adapt and respond to mobile app attacks and threats in real-time. Using Threat-Events will ensure you keep users, data, and transactions safe.

Mobile Application Threat-Events vs. Threat-Scores

Appdome Threat-Events can be used as a stand-alone implementation in Kotlin Apps, or in combination with Threat-Scores. Threat-Events provide the mobile developer with the in-app notification of each attack or threat, as well as the metadata associated with the attack. Threat-Scores provide the mobile developer with the Threat-Event event score and the combined (aggregate) mobile end-user risk at the time of the notification.

The figure below shows where you can find Threat-Events and Threat-Scores for each of the runtime mobile app security, anti-fraud, anti-malware, mobile antibot, and other protections available on Appdome:

Threat Events™, In App Threat Intelligence In Native Ios Apps

To enable Threat-Events with any runtime protection, select the check box next to Threat-Events for that feature. Doing so will enable (turn ON) Threat-Events for that feature. To enable Threat-Scores for any runtime protection, click the up/down arrow associated with Threat-Scores to assign a specific score to each protection.
Threat-Scores must have a value greater than zero (0) and less than a thousand (1,000).

Threat-Events and Threat-Scores can be used with or in place of server-based mobile anti-fraud solutions.

Prerequisites for Using Threat-Events with Kotlin Apps

Here’s what you need to use Threat-Events with Kotlin Apps.

Code Snippet Required for Using Threat-Events with Kotlin Apps

Before consuming Threat-Events or Threat-Scores in your Kotlin Apps, confirm that the following conditions are met:

  • Threat-Events and/or Threat-Scores have been enabled ( turned ON) for the specific protection
  • You are using the correct identifiers for the Threat-Events for each protection.
    You can find the specific identifiers for each Threat-Event and Threat-Score in the knowledge base article associated with each protection.

Below is the code snippet required for using Threat-Events™ and Threat-Scores™ in Kotlin Apps:

  • Update your Application class:
import android.app.Application
import android.content.Context
class MyApp : Application() {
    private var threatEventsReceiver: ThreatEventReceiver
    override fun onCreate() {
        super.onCreate()
        // Creating ThreatEventReceiver Instance with Application Context.
        threatEventsReceiver = ThreatEventReceiver(applicationContext)
    }
}
  • Implement your ThreatEventReceiver:
import android.content.BroadcastReceiver
import android.content.Context
import android.content.Intent
import android.content.IntentFilter
import android.os.Build
import android.util.Log
class ThreatEventReceiver(applicationContext: Context) {
    private val TAG = "Appdome ThreatEvent"
    private val context: Context = applicationContext
    private val receiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context, intent: Intent) {
            onEvent(intent)
        }
    }
    private fun registerReceiverWithFlags(intentFilter: IntentFilter) {
        Log.i(TAG,"REGISTERING: ${intentFilter.getAction(0)}")
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
            context.registerReceiver(this.receiver, intentFilter, Context.RECEIVER_NOT_EXPORTED)
        } else {
            context.registerReceiver(this.receiver, intentFilter)
        }
    }
    init {
        registerReceiverWithFlags(IntentFilter("RootedDevice"))
    }
    fun onEvent(intent: Intent) {
        val action = intent.action ?: return
        when (action) {
            "RootedDevice" -> {
                val internalError = intent.getStringExtra("internalError") ?: ""
                val defaultMessage = intent.getStringExtra("defaultMessage") ?: ""
                val timeStamp = intent.getStringExtra("timestamp") ?: ""
                val deviceID = intent.getStringExtra("deviceID") ?: ""
                val deviceModel = intent.getStringExtra("deviceModel") ?: ""
                val osVersion = intent.getStringExtra("osVersion") ?: ""
                val kernelInfo = intent.getStringExtra("kernelInfo") ?: ""
                val deviceManufacturer = intent.getStringExtra("deviceManufacturer") ?: ""
                val fusedAppToken = intent.getStringExtra("fusedAppToken") ?: ""
                val carrierPlmn = intent.getStringExtra("carrierPlmn") ?: ""
                val deviceBrand = intent.getStringExtra("deviceBrand") ?: ""
                val deviceBoard = intent.getStringExtra("deviceBoard") ?: ""
                val buildHost = intent.getStringExtra("buildHost") ?: ""
                val buildUser = intent.getStringExtra("buildUser") ?: ""
                val sdkVersion = intent.getStringExtra("sdkVersion") ?: ""
                //
                // Respond to mobile app attacks and threats here
                //
            }
            // Add cases for other actions here...
            else -> {
                Log.e(TAG, "Unknown event received: $action")
            }
        }
    }
}

 

Threat-Event Failsafe Enforcement

Failsafe Enforcement provides app developers with the ability to manage when Appdome enforces specific detections. To utilize this feature, follow the steps below:

  1. Set the Threat Event of the selected feature to “In-App Detection” mode.
  2. Enable the Threat-Event Failsafe Enforcement option.

Once you have received the Threat Event and performed the necessary internal logic, you should post a notification named “EnforceThreatEvent” using Android’s Broadcast API with the userInfo received from the Threat Event. Below is the code snippet required for using Threat Event in Failsafe Enforcement configuration, with the RootedDevice event as an example:

val action = intent.action

when (action) {
    "RootedDevice" -> {
        //
        // Respond to mobile app attacks and threats here, as seen above
        //

        // Notify Appdome to enforce the Threat Event after Threat Event is handled
        val newIntent = Intent("EnforceThreatEvent").apply {
            putExtras(intent.extras)
        }

To learn more, please read Threat-Events in Android & iOS Apps Explained

Compatibility with Android 14

Following a security update introduced in Android 14 (API level 34), apps targeting Android 14 are required to explicitly specify whether a registered receiver should be exported to all other apps on the device. A SecurityException will be raised if a context-registered broadcast receiver is registered without passing either Context.RECEIVER_NOT_EXPORTED or Context.RECEIVER_EXPORTED. The receiver flags were introduced in Android 13 as part of “Safer exporting of context-registered receivers,” as seen here. Therefore, when registering a broadcast receiver for Threat Events, the call to register a context-registered BroadcastReceiver registration should include the Context.RECEIVER_NOT_EXPORTED receiver flag when the app targets Android 13 and above in order to ensure that the receiver will only accept broadcasts sent from within the protected app. For additional details, please follow this Android guide.

Meta-Data for Mobile Application Threat-Events and Threat-Scores

Below is the list of metadata that can be associated with each mobile application Threat-Event and Threat-Score in Kotlin Apps.

Threat-Event Context Keys
message Message displayed for the user on event
failSafeEnforce Timed enforcement against the identified threat
externalID The external ID of the event which can be listened via Threat Events
osVersion OS version of the current device
deviceModel Current device model
deviceManufacturer The manufacturer of the current device
fusedAppToken The task ID of the Appdome fusion of the currently running app
kernelInfo Info about the kernel: system name, node name, release, version and machine.
carrierPlmn PLMN of the device. Only available for Android devices.
deviceID Current device ID
reasonCode Reason code of the occurred event
buildDate Appdome fusion date of the current application
devicePlatform OS name of the current device
carrierName Carrier name of the current device. Only available for Android.
updatedOSVersion Is the OS version up to date
deviceBrand Brand of the device
deviceBoard Board of the device
buildUser Build user
buildHost Build host
sdkVersion Sdk version
timeZone Time zone
deviceFaceDown Is the device face down
locationLong Location longitude conditioned by location permission
locationLat Location latitude conditioned by location permission
locationState Location state conditioned by location permission
wifiSsid Wifi SSID
wifiSsidPermissionStatus Wifi SSID permission status
threatCode The last six characters of the threat code specify the OS, allowing the Threat Resolution Center to address the attack on the affected device.

Some or all of the meta-data for each mobile application Threat-Event and Threat-Score can be consumed in Kotlin Apps at the discretion of the mobile developer and used, in combination with other mobile application data, to adapt the business logic or user experience when one or more attacks or threats are present.

Using Conditional Enforcement for Mobile Application Threat-Events and Threat-Scores

Conditional Enforcement is an extension to Appdome’s mobile application Threat-Event framework. By using conditional enforcement, developers can control when Appdome enforcement of each mobile application protection takes place or invoke backup, failsafe, and enforcement to any in-app enforcement used by the mobile developer.

Verifying Threat-Events in Kotlin Apps

After you have implemented the required Threat-Event code in your Kotlin Apps, you can confirm that your Threat-Event implementation(s) is properly recognized by the Appdome protections in the Kotlin Apps. To do that, review the Certified Secure™ DevSecOps certificate for your build on Appdome.

In the Certified Secure DevSecOps certificate, the correct implementation of Threat-Events in your mobile application is seen below.

Androidtecert

In the Certified Secure DevSecOps certificate, an incorrect implementation of Threat-Events in your mobile application looks as seen below.

Threateventswrongimplementationandroid

For information on how to view and/or retrieve the Certified Secure DevSecOps certification for your mobile application on Appdome, please visit the knowledge base article Using Certified Secure™ Android & iOS Apps Build Certification in DevOps CI/CD

How Do I Learn More?

If you have any questions, please send them our way at support.appdome.com or via the chat window on the Appdome platform.

Thank you!

Thanks for visiting Appdome! Our mission is to secure every app on the planet by making mobile app security easy. We hope we’re living up to the mission with your project.

Appdome

Want a Demo?

Threat-Events™ UX/UI Control

GilWe're here to help
We'll get back to you in 24 hours to schedule your demo.