Detecting and Responding to Runtime Attacks

Static analysis catches vulnerabilities in your code. Obfuscation makes the binary harder to reverse engineer. But once your application is running in production, it faces a different category of threats: attacks that happen at runtime, against the live process. This guide explains what those attacks look like, why perimeter defenses miss them, and how to detect and respond to them from inside your application.

What Are Runtime Attacks

A runtime attack targets the application while it is executing. Instead of analyzing the binary offline (static analysis), the attacker interacts with the running process to modify its behavior, extract data, or bypass security controls.

The most common runtime attack categories are:

Hooking

Hooking frameworks like Frida, Xposed (Android), and Substrate (iOS) allow an attacker to intercept any function call in your application. They can read function arguments, modify return values, and replace entire method implementations at runtime. This is the primary tool for bypassing client-side security checks, extracting decrypted data from memory, and manipulating business logic.

Debugging

Debuggers like LLDB, GDB, and the Android Debug Bridge (adb) allow step-by-step execution of your code. An attacker can set breakpoints, inspect variable values, read memory contents, and modify program state. Debugging is often the first step in understanding how the application works before building a more automated attack.

Tampering

Binary tampering means modifying the application code or resources after compilation. On Android, an attacker can decompile the APK, patch the bytecode, and repackage it with a new signature. On iOS, similar modifications can be applied to a decrypted IPA. The modified application may have license checks removed, ads disabled, or malicious code injected.

Injection

Injection attacks target the application's data processing. SQL injection, NoSQL injection, XSS, LDAP injection, command injection, and path traversal all exploit the gap between untrusted input and trusted execution. These attacks target server-side applications where user input reaches a database query, shell command, or file system operation without proper validation.

Environment Manipulation

Rooted Android devices and jailbroken iPhones give attackers full control over the operating system. They can read any file on the device, intercept all network traffic, inject code into running processes, and bypass the sandbox that normally isolates applications from each other.

Why WAFs Are Not Enough

A Web Application Firewall (WAF) sits at the network perimeter and inspects incoming HTTP traffic. It can block known attack patterns like SQL injection strings in query parameters or XSS payloads in form data.

But a WAF has fundamental limitations:

No application context. A WAF sees HTTP requests. It does not understand your application's business logic, authentication state, or data flow. It cannot distinguish between a legitimate complex query and a SQL injection attempt that uses application-specific encoding.

Encrypted traffic blind spots. For mobile applications that use certificate pinning or custom encryption, the WAF cannot inspect the request payload at all.

No runtime visibility. A WAF cannot detect if someone is debugging your application, hooking its functions, or running it on a rooted device. These attacks do not generate HTTP traffic that a WAF can see.

High false positive rate. Without application context, WAFs tend to over-block legitimate traffic or under-block sophisticated attacks that do not match known patterns.

RASP (Runtime Application Self-Protection) works from inside the application. It has full context over the code execution, the data flow, and the runtime environment. It can detect attacks that are invisible to perimeter defenses.

How ByteHide Monitor Detects Runtime Attacks

ByteHide Monitor is a RASP solution that runs as part of your application. It is available for .NET, Android, and iOS.

Mobile: Hooking Detection

Monitor detects when hooking frameworks like Frida, Xposed, or Substrate are active on the device or attached to the process. It identifies hooking through multiple signals: process inspection, library loading patterns, and function integrity checks.

Mobile: Debugger Detection

Monitor detects when a debugger is attached to the application process. This covers LLDB, GDB, Android Debug Bridge, and other debugging tools. It checks for debugging indicators at multiple levels to prevent simple bypass techniques.

Mobile: Tamper Detection

Monitor validates the integrity of the application binary at runtime. If the APK or IPA has been modified and repackaged (with code patches, removed checks, or injected payloads), Monitor detects the modification.

Mobile: Environment Checks

Monitor detects compromised device environments: rooted Android devices, jailbroken iPhones, emulators, and virtual machines. Each of these environments indicates a higher risk of attack.

Server: Injection Prevention (.NET)

For server-side applications, Monitor intercepts and validates all data that flows through your application. It detects SQL injection, NoSQL injection, XSS, LDAP injection, command injection, and path traversal with full application context, not just pattern matching on HTTP traffic.

See .NET Monitor Documentation for setup and configuration.

Configuring Automated Responses

Detection alone is not enough. Monitor lets you configure automatic responses for each threat type through Workflow Automation.

Available response actions:

ActionWhat it does
AlertSend a notification to your dashboard and optional webhook
BlockTerminate the current session and block the device
LogRecord the incident for forensics without interrupting the user
TerminateForce-close the application immediately

Response Strategy

Not every detection warrants the same response. A practical approach:

High severity (hooking, debugger attached, binary tampered): Terminate the application or block the session. These are strong indicators of an active attack.

Medium severity (rooted/jailbroken device, emulator): Alert and log. Many legitimate users have rooted devices. Consider blocking only for high-security applications like banking or payments.

Low severity (VPN detected, developer mode enabled): Log only. These are weak signals that should be correlated with other indicators.

Cloud Panel Configuration

All response rules are configured in the Monitor Cloud Panel. You can update response rules without releasing a new version of your application.

Connecting Detection to Vulnerability Data

When you use Monitor together with Radar, you get a feedback loop between static analysis and runtime detection.

Radar identifies vulnerabilities in your code during development. Monitor detects when those vulnerabilities are being exploited in production. The Runtime Correlation feature connects the two: you see which Radar findings are associated with actual attack traffic.

This changes how you prioritize fixes. Instead of working through a list of vulnerabilities sorted by CVSS score (a theoretical severity rating), you can sort by actual exploitation. A medium-severity vulnerability that is being actively attacked in production takes priority over a critical vulnerability that nobody has tried to exploit.

Combining Static and Runtime Protection

For the strongest defense, combine Shield's build-time protection with Monitor's runtime defense.

Shield makes the code harder to analyze. Monitor detects and blocks attempts to attack the running application. Together, they address both static and dynamic attack vectors.

See Protecting a Mobile App Before Publishing for a complete implementation checklist that covers both Shield and Monitor.

Next Steps

Previous
Securing API Keys and Secrets
Next
OWASP Top 10 for Your Application