TriggerScope: Towards Detecting Logic Bombs in Android Applications [Fratantonio, Yanick, Antonio Bianchi, William Robertson, Engin Kirda, Christopher Kruegel, and Giovanni Vigna. "Triggerscope: Towards detecting logic bombs in android applications." In Security and Privacy (SP), 2016 IEEE Symposium on, pp. 377-396. IEEE, 2016.] Presented by Suzzie Yang

Threats to applications Malicious application logic Violate the expectations of the users Private sensitive data leakage eg. contextual information, GPS location, personal accounts Sophisticated malware designs increase stealthiness and becomes difficult to prevent and detect

What is logic bomb? Functionalities with condition check statements The malware is only activated under certain circumstances May appear as a perfectly legitimate action bypassing automatic analysis systems Example: Navigation typed app Time-related checks Locations checks

The attack is triggered under certain, narrow circumstances

State-of-art analysis Static analysis Base on permission sets Machine learning techniques Dynamic analysis Execution of data in real-time Modifications on Android framework and native libraries Main purpose is to analyse malware detection The definition of the application’s specific purpose and “normal” functionality are lacking

Proposed system: TriggerScope Trigger analysis technique Triggers are suspicious predicates (or checks) Suspicious checks for very specific conditions Focus on characterising the predicates Less attention with the behaviour itself Time, location and SMS related predicates Identify triggered malware through the identification of logic bombs

Overview of trigger analysis (1) Input: Android app Dalvik bytecode Step 1: Symbolic execution Records operations on relevant objects Annotated with expression tree Step 2: Predicate extraction Backward traverse of control-flow graph (CFG) Remove false dependencies Recovers intra-procedural path predicates

Overview of trigger analysis (2) Step 3: Predicate characterisation Appraise how suspicious/narrow a predicate is Base on type of comparison performed Step 4: Control dependencies Checks whether a suspicious predicate guards and sensitive operation Inter-procedural Step 5: Post-filter Filter out cases that match our definition of suspiciousness but that are clearly benign Output: Suspicious apps or benign apps

35 out of 9,582 benign apps flagged suspicious Experiment Dataset 9,582 benign apps: A mix of time, location and SMS related APIs 14 malicious apps: Developed by DARPA red team and real-world malware Result 35 out of 9,582 benign apps flagged suspicious

Each consecutive steps reduced the false positive rate to 0.38% Accuracy evaluation Each consecutive steps reduced the false positive rate to 0.38%

Criticism Seems like the author is only considering cases where predicates are checked against hard coded object values The trigger may be invoked by other means such as over the network Indirect modification of values at different circumstances Since their focus is on triggers and not their behaviour, the paper adopts a lenient of flagging suspiciousness Therefore contributing to the result of 0% false negative as almost the majority of the checks will be considered interesting as potential suspicious predicates.

Thank you Questions?