Compromising Adversary
This adversary has the capabilities to compromise a device, a piece of software or infrastructure. It is very impactful and hard to mitigate in most realistic environments.
Developer Machines
This scenario is commonly happening but usually out of scope for most security audits, as the hardening against this threat is often times not seen as feasible and other low-hanging fruits are prioritized.
Assumptions
An adversary has control over machines of developers contributing to a specific project. This happened with some kind of software backdoor or due to previous physical access.
Goals
Usually the adversary is trying to elevate privileges to access critical build and deployment resources, exfiltrate confidential information around the application structure and secrets, compromise other (more privileged) developer machines and other forms of lateral movement.
Capabilities
The capabilities are the same of a legit developer. It can be possibly restricted by usage of multi-factor protocols, where the adversaries can only hijack legitimate access requests and requires some form of interaction with the developer.
Deployment Infrastructure
This scenario is occasionally happening but usually out of scope for most security audits, as other low-hanging fruits are prioritized.
Assumptions
An adversary has control over machines responsible for deployment of an application. This happened with some kind of software backdoor, insecure infrastructure exposure or due to previous physical access.
Goals
Usually the adversary is trying to distribute compromised and malicious binaries to the application user base.
Capabilities
The adversary can create new releases based on manipulated code.
User Filesystem
Assumptions
An adversary has control over the filesystem of an application user and can manipulate arbitrary files. This could be achieved due to either a multi-user system with inappropriate access control or remote exposure through the application or other installed software.
Goals
Usually the adversary is trying to elevate privileges to execute code on the system, where the application is run. This can be achieved with operating system or application specific behavior.
Capabilities
The capabilities are similar to read and write access of the user. Restrictions on specific files could hinder or prevent access to sensitive or abusable files.
User Applications
Assumptions
An adversary has control over a running binary on the same user account as the target application.
Goals
Usually the adversary is trying to block or abuse functionality exposed to the local system. The specific goals highly depend on the type of the application.
Capabilities
The capabilities are the same of a legit application running on the same user account. The implications are highly depending on the operating system and general facilitated application isolation methods.
Network
This scenario is common but usually out of scope for most security audits, as the hardening against this threat is often times not seen as feasible and other low-hanging fruits are prioritized.
Assumptions
An adversary has control over network equipment, which is used to communicate with external services. This could be either in the local network of the user or between other hops in the network.
Goals
Usually the adversary is trying to pivot from network devices to the users machine, sniff sensitive data and secrets transmitted over the network and infer privacy relevant usage of remote systems.
Capabilities
The capabilities are similar to an ISP or local network router. It is possible to intercept, manipulate and drop packets transmitted over the network. Data can be stored indefinitely to apply decryption or replay attacks over long periods of time.
