Common Attack Pattern Enumeration and Classification
A Community Resource for Identifying and Understanding Attacks
View customized information:
An attacker leverages an adversary in the middle attack (CAPEC-94) in order to bypass the same origin policy protection in the victim's browser. This active adversary in the middle attack could be launched, for instance, when the victim is connected to a public WIFI hot spot. An attacker is able to intercept requests and responses between the victim's browser and some non-sensitive website that does not use TLS.
When an attacker intercepts a response bound to the victim, an attacker adds an iFrame (which is possibly invisible) to the response referencing some domain with sensitive functionality and forwards the response to the victim. The victim's browser than automatically initiates an unauthorized request to the site with sensitive functionality. The same origin policy would prevent making these requests to a site other than the one from which the Java Script came, but the attacker once again uses active adversary in the middle to intercept these automatic requests and redirect them to the domain / service with sensitive functionality. Any persistent cookies that the victim has in their browser would be used for these unauthorized requests. The attacker thus actively directs the victim to a site with sensitive functionality. When the site with sensitive functionality responds back to the victim's request, an active adversary in the middle attacker intercepts these responses, injects their own malicious Java Script into these responses, and forwards to the victim's browser. In the victim's browser, that Java Script executes under the restrictions of the site with sensitive functionality and can be used to continue to interact with the sensitive site. So an attacker can execute scripts within the victim's browser on any domains the attacker desires. The attacker is able to use this technique to steal cookies from the victim's browser for whatever site the attacker wants. This applies to both persistent cookies and HTTP only cookies (unlike traditional XSS attacks). An attacker is also able to use this technique to steal authentication credentials for sites that only encrypt the login form, but do not require a secure channel for the initial request to get to the page with the login form. Further the attacker is also able to steal any autocompletion information. This attack pattern can also be used to enable session fixation and cache poisoning attacks. Additional attacks can be enabled as well.
This table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
This table shows the views that this attack pattern belongs to and top level categories within that view.
This table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
A Related Weakness relationship associates a weakness with this attack pattern. Each association implies a weakness that must exist for a given attack to be successful. If multiple weaknesses are associated with the attack pattern, then any of the weaknesses (but not necessarily all) may be present for the attack to be successful. Each related weakness is identified by a CWE identifier.
CAPEC mappings to ATT&CK techniques leverage an inheritance model to streamline and minimize direct CAPEC/ATT&CK mappings. Inheritance of a mapping is indicated by text stating that the parent CAPEC has relevant ATT&CK mappings. Note that the ATT&CK Enterprise Framework does not use an inheritance model as part of the mapping to CAPEC.
Relevant to the ATT&CK taxonomy mapping (see parent )
More information is available — Please select a different filter.