|
|
|
|
 Description An adversary uses a TCP NULL scan to determine if ports are closed on the target machine. This scan type is accomplished by sending TCP segments with no flags in the packet header, generating packets that are illegal based on RFC 793. The RFC 793 expected behavior is that any TCP segment with an out-of-state Flag sent to an open port is discarded, whereas segments with out-of-state flags sent to closed ports should be handled with a RST in response. This behavior should allow an attacker to scan for closed ports by sending certain types of rule-breaking packets (out of sync or disallowed by the TCB) and detect closed ports via RST packets. Extended Description In addition to being fast, the major advantage of this scan type is its ability to scan through stateless firewall or ACL filters. Such filters are configured to block access to ports usually by preventing SYN packets, thus stopping any attempt to 'build' a connection. NULL packets, like out-of-state FIN or ACK packets, tend to pass through such devices undetected. Additionally, because open ports are inferred via no responses being generated, one cannot distinguish an open port from a filtered port without further analysis. For instance, NULL scanning a system protected by a stateful firewall may indicate all ports being open. Because of their obvious rule-breaking nature, NULL scans are flagged by almost all intrusion prevention or intrusion detection systems. Typical Severity Execution Flow Experiment An adversary sends TCP packets with no flags set and that are not associated with an existing connection to target ports. An adversary uses the response from the target to determine the port's state. If no response is received the port is open. If a RST packet is received then the port is closed.
Prerequisites
| The adversary requires logical access to the target network. NULL scanning requires the use of raw sockets, and thus cannot be performed from some Windows systems (Windows XP SP 2, for example). On Unix and Linux, raw socket manipulations require root privileges. |
Resources Required
| This attack can be carried out via a network mapper/scanner, or via raw socket programming in a scripting language. Packet injection tools are also useful for this purpose. Depending upon the method used it may be necessary to sniff the network in order to see the response. |
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 |
|---|
Confidentiality | Other | | Confidentiality Access Control Authorization | Bypass Protection Mechanism Hide Activities | |
Mitigations
| Employ a robust network defensive posture that includes a managed IDS/IPS. |
Notes Other Many operating systems do not implement RFC 793 exactly and for this reason NULL scans do not work as expected against these devices. Some operating systems, like Microsoft Windows, send a RST packet in response to any out-of-sync (or malformed) TCP segments received by a listening socket (rather than dropping the packet via RFC 793), thus preventing the adversary from distinguishing between open and closed ports. NULL scans are limited by the range of platforms against which they work. 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
[REF-33] Stuart McClure, Joel Scambray
and George Kurtz. "Hacking Exposed: Network Security Secrets & Solutions". Chapter 2: Scanning, pg. 56. 6th Edition. McGraw Hill. 2009.
|
[REF-128] Defense Advanced Research Projects Agency Information Processing Techniques Office and
Information Sciences Institute University of Southern California. "RFC793 - Transmission Control Protocol". Defense Advanced Research Projects Agency (DARPA). 1981-09.
< http://www.faqs.org/rfcs/rfc793.html>. |
[REF-34] Gordon "Fyodor" Lyon. "Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning". Section 5.5 TCP FIN, NULL, XMAS Scans, pg. 107. 3rd "Zero Day" Edition,. Insecure.com LLC, ISBN: 978-0-9799587-1-7. 2008.
|
|
 Content History | Submissions |
|---|
| Submission Date | Submitter | Organization |
|---|
| 2014-06-23 (Version 2.6) | CAPEC Content Team | The MITRE Corporation | | | Modifications |
|---|
| Modification Date | Modifier | Organization |
|---|
| 2018-07-31 (Version 2.12) | CAPEC Content Team | The MITRE Corporation | | Updated Attack_Prerequisites, Description, Description Summary, References, Related_Weaknesses, Resources_Required | | 2020-12-17 (Version 3.4) | CAPEC Content Team | The MITRE Corporation | | Updated Description, Execution_Flow, Mitigations, Notes | | 2022-02-22 (Version 3.7) | CAPEC Content Team | The MITRE Corporation | | Updated Description, Extended_Description |
More information is available — Please select a different filter.
|