Description An adversary registers a domain name one bit different than a trusted domain. A BitSquatting attack leverages random errors in memory to direct Internet traffic to adversary-controlled destinations. BitSquatting requires no exploitation or complicated reverse engineering, and is operating system and architecture agnostic. Experimental observations show that BitSquatting popular websites could redirect non-trivial amounts of Internet traffic to a malicious entity. Likelihood Of Attack Typical Severity Execution Flow Explore Determine target website: The adversary first determines which website to impersonate, generally one that is trusted and receives a consistent amount of traffic. | Techniques |
|---|
| Research popular or high traffic websites. |
Experiment Impersonate trusted domain: In order to impersonate the trusted domain, the adversary needs to register the BitSquatted URL. | Techniques |
|---|
| Register the BitSquatted domain. |
Exploit Wait for a user to visit the domain: Finally, the adversary simply waits for a user to be unintentionally directed to the BitSquatted domain. | Techniques |
|---|
| Simply wait for an error in memory to occur, redirecting the user to the malicious domain. |
Prerequisites
| An adversary requires knowledge of popular or high traffic domains, that could be used to deceive potential targets. |
Skills Required
[Level: Low] Adversaries must be able to register DNS hostnames/URL’s. |
Consequences 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.| Scope | Impact | Likelihood |
|---|
Other | Other | |
Mitigations
| Authenticate all servers and perform redundant checks when using DNS hostnames. |
| When possible, use error-correcting (ECC) memory in local devices as non-ECC memory is significantly more vulnerable to faults. |
Taxonomy Mappings 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
) References Content History | Submissions |
|---|
| Submission Date | Submitter | Organization |
|---|
| 2015-11-09 (Version 2.7) | CAPEC Content Team | The MITRE Corporation | | | Modifications |
|---|
| Modification Date | Modifier | Organization |
|---|
| 2017-08-04 (Version 2.11) | CAPEC Content Team | The MITRE Corporation | | Updated Architectural_Paradigms, Attack_Motivation-Consequences, Attack_Phases, Attack_Prerequisites, Description, Description Summary, Methods_of_Attack, Typical_Likelihood_of_Exploit, Typical_Severity | | 2018-07-31 (Version 2.12) | CAPEC Content Team | The MITRE Corporation | | Updated Attack_Phases | | 2019-04-04 (Version 3.1) | CAPEC Content Team | The MITRE Corporation | | Updated Related_Attack_Patterns | | 2020-12-17 (Version 3.4) | CAPEC Content Team | The MITRE Corporation | | Updated Related_Attack_Patterns | | 2022-09-29 (Version 3.8) | CAPEC Content Team | The MITRE Corporation | | Updated Related_Attack_Patterns |
More information is available — Please select a different filter.
|