For those who want to dig a little deeper into their organisation’s mobile threats, Traced CTO Matt Boddy demonstrates hunting for the Cerberus banking Trojan, using Traced Control.
Watch the video
Incident response has now become the cornerstone of cyber security teams the world over. It is supported by some excellent guidelines like the NIST guide to incident handling and ISO27035.
However, many teams around the globe don’t have any form of feasible incident response plan for mobile devices carrying company sensitive information, whether in the form of BYOD, COBO or COPE devices.
Understanding threats and identifying modern attacks in their early stages is key to preventing subsequent compromises.
NIST – Computer security incident handling guide
There are well established suggested process life cycles for incident handling provided by both NIST and ISO27035. These processes help teams become best equipped for tackling a threat and learning from it in the future. Both lifecycles are relatively similar in concept, although for the purposes of this documentation we will focus on the process provided by ISO27035.
Specifically we will focus on the detect, assess and respond sections of the lifecycle.
Detect
The Traced app which feeds into Traced Control uses deep learning to detect malicious apps. It makes these judgements based on similarity of features to previously known threats. There is also an allow and block list available, which will be discussed in more detail during the respond phase.
Detections made by Traced Control can be flagged up via email or pulled from the Control API by any SIEM platform or other event triaging tool. The aim of this detect phase on mobile platforms is to have the capability to detect any potential threat that could eventually become an incident. However, to keep this brief, in this article we solely focus on the detection of malicious apps on Android.
Assess
Events flagged by the Traced app will be synced back to Control within 15 minutes and will include app details. These details will include indicators of compromise (IOCs) and further information to help identify the intentions of the app. The IOCs should be noted down and used for further searching to assess the scope of the threat to the organisation.
Examples of such indicators of compromise which can be used for hunting include the following:
- MD5 hash
- SHA256 hash
- Signing certificate hash
- App name
The detection can be further understood by evaluating the permissions and intents of the app to determine the potential scope of the threat. Third party platforms such as VirusTotal in conjunction with the IOCs can be used to evaluate whether the threat is already known about or if this is unique to your organisation.
Now that the threat type has been evaluated, the app signing certificate hash and app hash should be used to search for and determine whether the app or its signer have affected devices before within the organisation. The earlier assessment phases can be repeated for every app discovered during this threat hunting and search phase.
Respond
Now that the scope of this threat is fully understood, it’s time to start locking it down. Any devices affected by the threat can have their access to business data immediately revoked using the integration between Traced Control and platforms like Microsoft Azure Active Directory. The earlier obtained IOCs can be used to create a block rule for any apps created by the same signing certificate.
