Hook Detection

Plan	Platforms	MASVS
Team	Android	MASVS-RESILIENCE-4

Overview

Hook Detection identifies signs that an Android app is running in an instrumented or manipulated runtime environment. It is designed for apps that need to detect dynamic analysis, runtime tampering, credential interception, automated abuse, or attempts to disable security checks while the app is running.

When a signal is detected, AppTego applies your configured response. Teams commonly begin with logging, then move sensitive journeys such as login, payments, account changes, wallet activity, or regulated data access to a stricter response after reviewing telemetry.

When To Use It

Use this control when your threat model includes:

Runtime manipulation of authentication, payment, licensing, or fraud logic.
Dynamic instrumentation during account takeover, scraping, or automated abuse.
Attempts to inspect secrets, API traffic, or protected business logic in memory.
High-value Android apps where root, emulator, debugger, and integrity signals should be evaluated together.

How It Works

The control evaluates several categories of runtime indicators and combines them into a detection decision. The public behavior is intentionally simple: the app checks for signs of instrumentation during startup or SDK initialization, then fires the configured response if the environment looks unsafe.

AppTego does not expose the exact signatures, thresholds, or inspection sequence in public documentation. Those details change as attacker tooling changes and are treated as part of the protection logic.

How to Enable the Control

Navigate to Detection & Response from the AppTego portal, and expand the Runtime Attack Detection section. Under this section you will find the Hook Detection control. Click Enable Configuration, choose the response action, and save the configuration for the next build or for it to be applied with a live push (if enabled).

API Configuration Example

{
  "HookDetectionResponse": {
    "detection": true,
    "action": "alert",
    "title": "Security Warning",
    "message": "This device environment appears unsafe. Please close any debugging or modification tools and try again.",
    "buttons": ["OK"],
    "actions": ["close"],
    "redirects": [""]
  }
}

Field	Purpose
`detection`	Enables or disables runtime hook detection.
`action`	Selects the response style, such as alert, close, log, or warn.
`title` / `message`	User-facing text shown when a response is displayed.
`buttons` / `actions` / `redirects`	Defines the available response buttons and their outcomes.

Response Strategy

Rollout stage	Recommended response
Evaluation	Log detections and compare them with fraud, support, and device data.
Limited rollout	Warn users or restrict only the highest-risk flows.
High-risk production flows	Close the app or block the sensitive action when the signal is high confidence.

Compatibility Notes

Legitimate internal testing tools can trigger this control. Use a development configuration or logging response for QA builds.
Some crash reporting, analytics, or debugging SDKs may use runtime techniques that resemble instrumentation. Test release builds with all production SDKs enabled.
No runtime detection can guarantee coverage against a fully controlled device. Pair this control with Root Detection, Emulator Detection, Debuggable Detection, App Tamper Detection, and server-side fraud controls.
Detection is most useful when response decisions are based on risk. A hard block may be appropriate for banking, wallet, DRM, healthcare, or enterprise apps, while consumer apps may prefer warning or logging.