Bcrypt password cracking extremely slow? Not if you are using hundreds of FPGAs!

Bcrypt password cracking extremely slow? Not if you are using hundreds of FPGAs!

Original text by ScatteredSecrets.com

Image for post

Cracking classic hashes

Moore’s law is the observation that the number of transistors in a dense integrated circuit doubles about every two years. This roughly doubles computing power about every two years as well. Password hashing algorithms typically have a lifetime of many decades. This means that the level of protection of a given password hash algorithm decreases over time: attackers can crack longer and more complex passwords in the same amount of time.

The introduction of powerful Graphics Processing Units (GPUs) and supporting software frameworks revolutionized password cracking. Starting over a decade ago, high performance GPU password cracking tools were published, massively outperforming Central Processing Units (CPUs) that were typically used for password cracking at the time. The speed-up was a factor of 50 to 100 for many algorithms: another big step back for the protection level of your passwords. The impact of the combination of Moore’s law and the introduction of GPUs is massive.

Let us take a closer look at a classic password hashing algorithm that was very popular a decade ago and still is in use today: MD5. The hash rate —the number of passwords that can be guessed — on an decade old AMD Phenom II X4 965 CPU was about 95M hashes per second. On a recent Nvidia RTX 2080Ti high-end GPU, the hash rate is about 54,000M hashes per second: about a factor 570 faster. Similar speed-ups can be seen for other classic password hashing algorithms like SHA-1 and SHA-2. It is clear that classic password hashing algorithms are losing the battle. And it is clear that the GPU is the weapon of choice for cracking classic password hashes.

Advanced hashes

Some password hash designers recognized the importance of designing algorithms that could cope with ever increasing computing power. They introduced two new characteristics: a variable iteration count and memory hardness.

Using a variable iteration count is a way to make password cracking more time consuming by requiring repeated hashing. The number of rounds for repeated hashing is configurable. This allows the algorithm to stay resistant to password cracking attacks even if computation power significantly increases: if computing power doubles the iteration count can also be doubled, resulting in a similar hash rate.

Memory hardness is used to slow down specific hardware platforms by using a relatively large amount of memory to calculate a password hash. If the amount of required memory is higher than the amount of local fast memory available to the computing core (‘level 1 cache’), the computing core needs to wait for data from slower memory. This will result in a significant drop in performance. For some memory hard algorithms the required amount of memory is fixed. If the cracking platform has more level 1 cache on board, the algorithm’s countermeasure is ineffective. For other algorithms, the memory usage is variable and can simply be set to a value higher than the amount available in the most potent attack platform. This value can be updated over time. So having more computing power only is not good enough to accelerate password cracking, the platform also needs enough fast memory to fit the entire algorithm in.

In the last decades, a number of advanced password hashing algorithms was introduced. The most well-known ones are bcrypt (1999), scrypt (2009) and Argon2 (2015). All use a configurable iteration count. Memory usage of bcrypt is fixed, the others also support configurable memory usage.

Meet bcrypt

Scattered Secrets is a password breach notification and prevention service. We continuously collect publicly available hacked databases and try to crack the corresponding passwords. The majority of breached databases we encounter contain classic hashes, but the number of databases that contain advanced hashes is increasing — typically deploying bcrypt hashes. Even though both scrypt and Argon2 are better choices because of the configurable memory usage, it seems that those two are not used on a large scale yet.

Taking a closer look at bcrypt hashes, we see that the configurable iteration count in bcrypt is called the ‘work factor’. The work factors we see in the wild vary between 7 and 14, meaning between 2⁷ = 128 and 2¹⁴ = 16,384 iterations.

Image for post

Let us check the hash rates for all real-life work factors on both an AMD EPYC 7401P and an Nvida RTX-2080Ti, a CPU and a high-end GPU with comparable prices. For completeness, work factor 5 is also included, since this is the de-facto standard for benchmarking purposes.

Image for post
Figure 2: bcrypt hash rates, CPU versus GPU

It is clear that the hash rate on both CPU and GPU is extremely low compared to the 54,000M hashes per second for MD5 on a GPU.

It is also clear that the memory hardness of the 1999 algorithm is still good enough in 2020 to slow GPUs down: the 50 to 100 times advantage over the CPU is completely gone. The reason is obvious if you take a closer look at the internals of bcrypt and the specifications of the heart of the GPU, in this case the Turing TU102. Bcrypt needs over 4 kilobyte of fast memory to run at full speed. The TU102’s 4,352 cores have only 1 kilobyte of level 1 cache available per core, meaning that the cores are spending a lot of time waiting for access to slower memory. In contrast, the used CPU has a level 1 cache of 96 kilobyte (32 kB for data, 64 kB for instructions) per core, so no delays there.

Conclusion? Cracking bcrypt hashes on a CPU or GPU is not very effective. Anything other than a very basic dictionay attack is unfeasable. We need something different.

FPGAs to the rescue

Field Programmable Gate Arrays (FPGAs) are chips that can be programmed for a special application after manufacturing. Unlike a CPU or GPU, FPGAs do not run code. Instead an FPGA is the code, build in hardware. This means that FPGAs can be programmed as dedicated optimized password hashing circuitry. Although FPGA clock speeds are significantly lower than those of CPUs and GPUs — typically hundreds of Megahertz versus a few Gigahertz — the dedicated circuitry runs more efficiently. This is true for both performance per Megahertz and performance per Watt.

The first commercial FPGA-based crackers were available in the mid 2000s. It took many years before the first free and open source password crackers became available. In 2016, the community enhanced version of John The Ripper started supporting the ZTEX 1.15y: quad Spartan-6 LX150 FPGA boards that were quite popular for mining cypto currency in earlier years. With the release of version 1.9.0-jumbo-1 in 2019, John The Ripper officially added support for 7 hash types including bcrypt. Although the boards — introduced in 2011 — are not using the latest generation of FPGAs, they are good enough to run 124 optimized bcrypt cores per FPGA. This results in a high bcrypt hash rate: higher than the hash rate of the latest generation of high-end GPUs:

Image for post
Figure 3: bcrypt hash rates

A single quad FPGA board from 2011 outperforms a latest generation RTX-2080Ti GPU with factor of over 4. For Scattered Secrets it was clear that using john with the ZTEX boards was the way forward for bcrypt cracking.

From proof of concept to production v1

The ZTEX 1.15y board is a discontinued product. Although the boards were popular for crypto currency mining, the availability on the second hand market was and is limited. Finding boards was a challenge. It took us almost two years of monitoring several online market places until we were able to find boards at large quantities. Once found, buying the devices was challenging as well. Sellers typically want to stay anonymous so checking trustworthiness is an issue. Hardware escrow? Coming from professional corporate environments the processes used looked… interesting… to us. The only accepted payment method? Crypto currency. Testing or pick-up in person? No way. All ingredients of a good scam. No guts no glory, after transferring Bitcoins to our anonymous friends, we have aquired a large number of boards of which almost all were in working condition.

In early 2019 we built out first FPGA cracker, based on 12 ZTEX boards and an Intel J4005 based PC. This machine was mainly used for testing the concept for large scale deployment in production.

Image for post
Figure 4: proof of concept / production v1 setup

We used 12 FPGA boards for a number of practical reasons. First of all, 12 devices can be connected using two of the shelf USB hubs, so switching hardware during testing or in case of issues in production does not require waiting for shipments of exotic products and is inexpensive. Secondly, 12 devices can be easily build into an off the shelf 4U case by non-experts. Thirdly, common specs power supplies can be used.

The initial system design was performing surprisingly well: FPGA performance scaled perfectly, system cooling performed above expectation, the controller PC had more than enough computing power to keep all FPGAs busy and the system was stable. After a two month test period and some minor upgrades, the first v1 system was put into production and has so far been running without noticeble issues.

Image for post
Figure 5: from zero to (datacenter) hero

Production v2

With the high bcrypt hash rate of the now proven concept, it was clear that using more FPGA-based crackers was on top of our wishlist. Preparations started as soon as the first v1 system was in production. To maximize performance per system and to professionalize construction, we contacted an instrument maker. His design simplified the setup and added another 6 FPGA boards per system, totaling at 18 boards / 72 FPGAs now.

Image for post
Figure 6: simplified design with 6 boards per row (x3 rows)

The hardware setup is very similar to the v1 design: the only major changes include a more powerful and more efficient power supply and exotic USB many port hubs to connect all 18 FPGA boards to the controller PC using two USB hubs.

Image for post
Figure 7: the first completed production v2 setup

The number of issues was quite limited. Problems were mainly related to the USB hubs. It seems that some USB hubs require more power than the PC mainboard can provide. Other USB hubs were unreliable: USB connectivity dropped during longer test runs. Finally, specifications of some Chinese manufacturers were incorrect, not providing USB 2.0 (480 Mbps) links as promised, but USB 1.1 (12 Mbps) which is too slow to keep the FPGAs working at full speed. Thorough testing showed that HS8836-based hubs were the most reliable.

Image for post
Figure 8: USB chips

After some minor design updates, the first v2 system was ready. Three clones quickly followed. After successful burn-in tests, the first set of four v2 systems was moved to production in late 2019.

Image for post
Figure 9: a new set of bcrypt v2 crackers ready for production

A picture of a stack of FPGA crackers posted on social media resulted in a number of questions. Most questions are answered above. The most important ones are not: what is the hash rate and what is the power usage of one of the bcrypt crackers? Here you go:

Image for post
Figure 10: performance and power usage of a v2 cracker

To translate the figures to GPU performance: to match the bcrypt crunching power of a single v2 cracker, you need about 75 to 80 Nvidia RTX-2080Ti GPUs. That is one FPGA-based machine versus a server rack full of GPU-based systems, burning about 25 kilowatts of power! So FPGA-based cracking is not only fast, it is also relatively economical to run.

After running many FPGA-based systems for months in production now, we have cracked an enormous number of bcrypt hashes that were previously practically uncrackable using conventional hardware. This allows us to generate a lot of quality content, allowing our clients to protect their accounts against account takeover with our unique intel. Scattered Secrets ♥ passwords 😉 Don’t forget to check if your passwords are breached!

Edit Aug-2020: original GPU benchmarks were based on hashcat 5.1.0 using OpenCL. Since publication, hashcat’s bcrypt performance was improved significantly and hashcat 6 was introduced, using CUDA. As a result, the bcrypt hash rate for work factor 5 on hashcat 6.1.1 using CUDA on a RTX 2080Ti is now ~53k/s instead of the original ~28k/s.

The Powerful HTTP Request Smuggling

The Powerful HTTP Request Smuggling

Original text by Ricardo Iramar dos Santos

TL;DR: This is how I was able to exploit a HTTP Request Smuggling in some Mobile Device Management (MDM) servers and send any MDM command to any device enrolled on them for a private bug bounty program.

Image for post
I am inevitable

What is HTTP Request Smuggling? 📖

If you already know what is HTTP Request Smuggling you can skip this section but if you want to know the basics I’d recommend read carefully.

In this section I’ll try to put everyone under the same page covering only the basics about HTTP Request Smuggling. If you want to learn in details I recommend you read this documentation https://portswigger.net/web-security/request-smuggling, read all the references and do all the labs.

In August 2019 when James Kettle brought HTTP Request Smuggling back from the ashes I tried to understand this vulnerability and at that time it was difficult to me understand everything.

Now after exploiting a few instances I see the problem to understand at the first glance. Most of the time we are looking for a vulnerability on the application and HTTP Request Smuggling also involves another layer called network.

The images from now one in this section are from this YouTube video “$6,5k + $5k HTTP Request Smuggling mass account takeover — Slack + Zomato”. Thanks Grzegorz Niedziela for allowing me to use the images! I strong recommend you to watch this video after reading this post.

Before talking about HTTP Request Smuggling itself lets recap some features from HTTP protocol version 1.1. A HTTP server can process multiple requests under the same TCP connection as you can see in the example below.

Image for post

The header Content-Length defines the size of the body which tells to the server where the body finishes. There is another header called Transfer-Encoding which also defines the size of the body.

Image for post

The Transfer-Encoding header indicates the body will be sent in chunks and the numbers in the beginning of each chunk indicates the size of it in a hexadecimal format. The last chunk should be indicate with number 0 which determines the end of the body.

The main difference between Content-Length and Transfer-Encoding is in the first case the request send the entire body at once and on Transfer-Encoding the body is sent in pieces.

But what happen when both headers are present?

Image for post

The RFC 2616 is clear on section 4.4 Message Length page 34 about it.

If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

RFC describes the beauty of the theory but this is not what happen in practice. When an environment do not respect the sentence above the HTTP Request Smuggling is possible.

Nowadays is pretty common to see web applications in the back-end and a reverse proxy in the front-end like the diagram below.

Image for post

What happen if Bob sends a request with Content-Length and Transfer-Encoding and front-end and back-end interprets these headers in a different order ignoring RFC 2616? Let’s assume Alice also sends a request right after Bob with only the Content-Length header.

Image for post

In the image above we can see Bob and Alice requests one next to another. The Bob’s request comes first and the front-end is using the Content-Length header (ignoring Transfer-Encoding) to defines the body length which means for the front-end Bob’s request ends right after the text key=value and Alice’s request starts at POST / HTTP/1.1.

In the other side back-end is using Transfer-Encoding header (ignoring Content-Length) and defining the end of Bob’s request at the number 0 and assuming the Alice’s requests starts with the text key=value which is an invalid request.

If Bob is a skilled attacker he can craft a malicious request and force Alice to receives a different response from what was supposed to be the original response from Alice’s request.

That’s the most important part of HTTP Request Smuggling. If you didn’t get what is happening here I strong recommend you go back and read everything again.

Reporting HTTP Request Smuggling📝

I was scanning some subdomains using Smuggler in a private bug bounty program on Hackerone when I initially found 13 subdomains reported as potential vulnerable to HTTP Request Smuggling by Smuggler. I reported all of them in one single report as critical even without a real PoC because I was afraid to get a duplicate and decided to work on the impact later. I got that felling there was something big which would require time to investigate.

If you already ran Smuggler before you probably know most of the time Smuggler reports as potential vulnerable but you cannot really get any real impact directly. For each case a research is required to understand the context and test a malicious scenario to prove the impact.

The most common impact that I’ve seen it is what I called as Universal Redirect. Universal Redirect is when you can force any user to receive a malicious response which actually redirects the user to another domain.

As usual the Hackerone triager asked me for a PoC with a valid impact which is a fair enough request. From those 13 subdomains reported as potential vulnerable I was able to quickly found one vulnerable to Universal Redirect by just sending the request below.

Image for post

The request above was pointed to one of the 13 subdomains. Since I cannot reveal anything regarding the company let’s say the requests was actually made to https://vulnerable.requestsmuggling.com. As you can see instead of using vulnerable.requestsmuggling.com on the Host headers I’ve changed to www.example.com in order to get a redirect in the response pointed to it.

By playing the attacker with the request above the luckiest next user making any request to https://vulnerable.requestsmuggling.com would receive the response below generated by my malicious request.

Image for post

Without knowing what is happening and totally transparent the next user would be magically redirected to https://www.example.com/getfile/. If I keep sending the same request described above I’d be able to redirect almost all the users to a domain that I control.

After been able to demonstrate the Universal Redirect above I also found other 4 subdomains (17 subdomains in total) identified as vulnerable by Smuggler and included them under the same report. At that time I didn’t look closely to these 4 new subdomains. The Hackerone triager accepted my report and downgrade the severity from critical (9.1) to high (7.5) which later on the company changed from high (7.5) to critical. 🤷‍♂️

As soon as my report was validated I asked permission to try other scenarios which could affect real users and got this answer below from the Hackerone triager.

I passed your report to the company team, please don't perform any activity that might affect live users before hearing back from the team.

HTTP Request Smuggling is really powerful and if you don’t what you doing you can impact all the users. I just continued with my investigation to see what else impact I could prove with all those instances.

The First Bounty 💰

After four days from the date that I opened the report someone from company commented in the report asking for more details how to reproduce for a specific subdomain and as much as possible to avoid test on production subdomains. By the subdomain names it was easy to identify which subdomains were production and which were not.

After providing all the details how to reproduce the Universal Redirect for one subdomain I was rewarded with a US$2,000 bounty. In order to elevate the bounty I checked all the subdomains and from those 17 subdomains I was able to demonstrate the Universal Redirect only for 7 subdomains.

I didn’t agree with the bounty because I knew it with those 7 vulnerable subdomains I could cause a big impact in their business by just redirecting all the users to a malicious domain. I complained through the comments and got the comment below from the company.

The bounty payment was based on the number of unique systems affected and the maximum perceived impact of the vulnerability (redirection).

That is fair enough, I decided to take a close look on the others 10 subdomains to see what I could get from them.

Trying Harder ⚔️

I tried for a few days to get some impact on those 10 subdomains but got nothing. I was trying harder because some of them subdomain names had api in the middle. If I could redirect the traffic from those APIs to another domain under my control maybe I could get some sensitive information.

After trying everything I decided to go back to the other 7 subdomains to check if I was missing something and the subdomain mdm.qa-vulnerable.requestsmuggling.com took my attention.

A few months back I had some experience working with a Mobile Device Management (MDM) solution and I knew it a little bit about the MDM protocol so I decided to investigate more in details the subdomain mdm.qa-vulnerable.requestsmuggling.com. I was really comfortable to work on this subdomain since the name was clear saying this is a QA environment.

First step was redirect a random request to Burp Collaborator to see if I could get a request from a random user and analyze it. I’ve created my payload, sent the request below and waited.

Image for post

After a few seconds I was able to see the request below in my Burp Collaborator.

Image for post

By the request headers “Content-Type: application/x-apple-aspen-mdm”, “Mdm-Signature: …” and “User-Agent: MDM/1.0” we can assume this request came from a MDM client. A quick google search returned the Mobile Device Management Protocol Reference document as the first hit.

Image for post

After the enrollment the devices start to listen for a push notification from the server. To cause the device to poll the MDM server for commands, the MDM server sends a notification through the APNS gateway to the device. The message sent with the push notification is JSON-formatted and must contain the PushMagic string as the value of the mdm key.

Since I didn’t have the mdm key and I’m not sure if we could send a notification through the APNS gateway to the device I’ve checked what happen next. The device responds to this push notification by contacting the MDM server using HTTP PUT over TLS (SSL) which matches with our Burp Collaborator request. This message may contain an Idle status or may contain the result of a previous operation. I though the requests that I was seeing on Burp Collaborator were Idle status since it was Sunday so I didn’t think anyone was sending commands to devices in a QA environment.

From the documentation we can see the MDM clients follow HTTP 3xx redirections without user interaction and in case of mdm.qa-vulnerable.requestsmuggling.com there is no client certificate authentication since we can see the header Mdm-Signature on the request.

If your MDM server is behind an HTTPS proxy that does not convey client certificates, MDM provides a way to tunnel the client identity in an additional HTTP header. If the value of the SignMessage field in the MDM payload is set to true, each message coming from the device carries an additional HTTP header named Mdm-Signature.

Image for post

My attack scenario was based in the way the MDM protocol works. From the documentation we can see after execute one command a device will wait for the server finish the process or sending more commands.

Image for post

In theory I could inject a redirection and replace the server response that pretends to finish the process and redirect the device to a fake MDM server which would send another command instead. To do that I got the example below from the document which sends a command to install an application on the device.

Image for post

As you can see from the documentation the user needs to accept the request in order to install the application. Since the attack is kind of blind I created a test Python server and hosted under https://myattackerdomain.com with the example above and add the parameter ManifestURL pointing to Burp Collaborator to see if I’d receive any feedback which unfortunately it didn’t happen.

After running my fake server for a few minutes and perform the attack pointing the redirection to https://myattackerdomain.com/api I was able to see just a few requests coming to my server. I’m not sure if these requests were coming from real MDM devices and since it was a QA environment I didn’t think there was much traffic from devices to the server.

Image for post

I was afraid to violate their policy so I decided to stop and send all the information above to the company and after that I got the answer below.

If you are able to prove that the vulnerability can be used for more than redirection, like gaining access to sensitive information, we can re-evaluate the reward.

No Retreat! No Surrender! 🥋

I decided to give a try on production since I wasn’t seeing much traffic in any other server. I did the same attack as before but now on mdm.prod-vulnerable.requestsmuggling.com and I got the response from the devices for valid server commands.

I also did a little improvement in my server to print the requests and reply with a response for the “ProfileList” command using this documentation as example. The screenshot below is from this python BaseHTTP server.

Image for post

In order to prove that I could execute MDM commands I got a valid CommandUUID from one of the outputs and changed one letter to be sure it would be a unique CommandUUID and did the same attack again.

By keep doing the same attack I got another request (which is the command response to the server) with the exactly same CommandUUID from my payload proving that I was able to execute the ProfileList MDM command in any client.

At this point there was nothing else to attack so I included everything in my report and started to press F5 waiting for the response below.

Alright! I think this proves your point much better. Based on the impact even just testing can have on active devices, please stop testing this while we investigate further.

After that the company asked a few questions about the attack and one thing that I highlighted to them was about the clients following the redirects. The RFC 2616 states it should send the data through the redirect URL but the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user.

In the MDM context it would be impracticable for a user accept all possible redirects that’s why in the MDM documentation it’s describing the 301 redirect will be automatically followed but it won’t be remember it. I have no idea why the clients needs to blindly follow the redirects.

Image for post
Image for post

After some days when everything was confirmed as fixed I was rewarded with the maximum payout US$15,000 bounty and a US$50 bonus. In total I got US$17,050 for this report. 🤑

The company was really nice and also told me they created a lab to test the same attack but using the EraseDevice command. Below you can check their on comments about the results.

A few seconds later, we hear on the call the iPad had rebooted and was showing a progress bar. About a minute later, the iPad rebooted again and showed the default iOS setup screen. A complete device wipe!

Bonus Track 🏆

After receiving the bounty I asked the company if I could publish this post of course without mention their name or anything related to their company. They replied back saying to wait for a few days because some vendors were involved and they wanted to check if others costumers could have the same problem.

It took more than few days but finally I got the answer below.

Good news! Citrix has released their security bulletin and have credited you in it, as well as in their hall of fame!Bulletin - https://support.citrix.com/article/CTX281474
Hall of Fame - https://www.citrix.com/about/trust-center/vulnerability-process.htmlYou should be all set to go ahead and publish your report.
Image for post
Image for post

Unfortunately Citrix doesn’t have any bug bounty program but at least I was recognized in their portal.

If you have any question or want to share any interesting technique about HTTP Request Smuggling please send email to ricardo.iramar@gmail.com or contact me on twitter @ricardo_iramar.

Deep Dive Into Nmap Scan Techniques

Deep Dive Into Nmap Scan Techniques

Original text by PenTest-duck

Disclaimer: I won’t be covering “every” scan type (e.g. -sY, -sM), but I’ll cover the scan types that I think will be used more often.
A More Serious Disclaimer: using Nmap against a target or network without explicit permission is illegal and should therefore not be attempted.


Image for post

nmap -h SCAN TECHNIQUES output

So if you’re like me and have done man nmap or nmap -h to see what Nmap has to offer, you’ll notice it prints lines and lines of output. In this blog post, I’ll try and demystify many of the scan techniques it has to offer, including some uncommon ones that you may never have to use in your life.

TCP Connect Scan (-sT)

Syntax: nmap -sT <target-ip> [-p <ports>]
Let’s kick this off with one of the more common ones. Personally, I rarely ever use -sT unless -sS doesn’t work (but if -sS doesn’t work, I doubt that -sT is going to work, either). Nevertheless, it is good to know how a TCP Connect scan works and how Nmap can leverage TCP to reveal port status. Basically, TCP Connect scans utilise TCP’s connection-oriented nature to attempt to perform a full 3-way TCP handshake with each port and verify its state.

Image for post
TCP Connect Scan captured in Wireshark (23 = closed, 22 = open)

Nmap sends a SYN packet to initiate the 3-way TCP handshake. If the port is closed (look at top 2 packets), the port replies with a RST-ACK, to terminate the connection.

If the port is open (look at next 5 packets), the server replies with a SYN-ACK, and Nmap completes the 3-way handshake with an ACK packet. Then (after the port updates the window [search “TCP sliding window”]), Nmap immediately terminates the connection with a RST-ACK packet.

Pro: quite reliably scans TCP ports
Cons: less “stealthy” (connection attempts will be logged by the server), takes a longer time, sends more packets

TCP SYN (“Stealth”/“Half-Open”) Scan (-sS)

Syntax: nmap [-sS] <target-ip> [-p <ports>]
The SYN scan is the default scan of Nmap, and it goes by many names, the first referring to its sneaky nature of avoiding connnection attempts from being logged by the server (nowadays, the SYN scan is not so stealthy anymore). But how does it achieve this? The second name explains it — “Half Open” refers to SYN scan’s method of performing only 2 steps of the 3-way TCP handshake. We never send the third and last packet, and instead terminate the connection, therefore allowing Nmap to verify the port’s status without fully connecting to the port.

Image for post
TCP SYN Scan captured in Wireshark (23 = closed, 22 = open)

ust like the TCP Connect scan, Nmap sends a SYN packet to initate the handshake, and if the port is closed, receives a RST-ACK (packets 1, 3).

However, this time, if the port is open, after Nmap receives the SYN-ACK, it
immediately sends a RST packet to terminate the connection, as it has verified that the port is open due to it responding with a SYN-ACK (packets 4,5).

Pros: quicker and sends less packets
Con: with advancements in firewall and server defenses technology, it is not stealthy anymore

UDP Scan (-sU)

Syntax: nmap -sU <target-ip> [-p <ports>]
UDP Scanning utilises UDP and ICMP packets to discover the status of a port. Nmap sends an empty UDP packet and either receives no reply or an ICMP Port Unreachable packet. But due to UDP’s connectionless nature, the output can be unreliable at times.

Image for post
UDP Scan captured with Wireshark (88 = open, 89 = closed)

Nmap sends an empty UDP packet for both ports (packets 1,2,4) and receives no reply from port 88 twice(open) and an ICMP Port Unreachable packet (packet 3) from port 89 (closed).

But Nmap returns this output:

Image for post
Nmap returns “open|filtered”

What’s up with the “open|filtered” instead of “open”?
Here’s the thing: when Nmap received no reply from port 88, one scenario could be that port 88 really is open, and is therefore not responding with any reply, however, another possible scenario is that a firewall is filtering out our traffic and thus the UDP packet never reaches the target and we receive no reply. Either way, we won’t know the difference — which results in Nmap displaying “open|filtered”.

Pros: allows the scanning of UDP ports
Cons: not always reliable

Null, FIN & Xmas Scans (-sN, -sF, -sX)

Syntax: nmap {-sN -sF -sX} <target-ip> [-p <ports>]
Now we get to the scan techniques that we will come across much less often. All of Null, FIN and Xmas scans are intended to stealthily sneak through stateless firewalls and packet filters, by turning on different TCP flags
Null scan: no flags set
FIN scan: FIN flag set
Xmas scan: FIN, PSH, URG flags set (packet lights up like a Christmas tree, hence the name)

Image for post
Null, FIN and Xmas scan captured in Wireshark (22 = open, 23 = closed)

For all of the scans, the underlying procedure is the same, except for the flags. If a port is closed, it replies with a RST-ACK and if it is open, it does not reply. However, this is not the case for all machines as not every machine follows RFC 793 and can send a RST packet even though the port is open. Additionally, since these scans rely on open ports not replying back (like UDP scan), it also suffers the issue of us not knowing if a firewall has filtered our packets or not (thus our output of “open|filtered”).

Pro: can sneak through some firewalls and packet filters
Cons: not all machines conform to RFC 793, not always reliable

ACK Scan (-sA)

Syntax: nmap -sA <target-ip> [-p <ports>]
Now, the ACK scan is a little bit different to what we’ve looked at so far. The ACK Scan isn’t meant to discover the open/closed status of ports. Instead, it helps us visualise the rulesets of intermediary firewalls. As the name suggests, Nmap sends TCP packets with only the ACK flag set, and if it receives a RST packet (both open and closed ports will respond with a RST), the port is marked as “unfiltered”, but if it receives no reply, or an ICMP error, the port is marked as “filtered”, and the firewall has filtered the packet.

Image for post
ACK Scan captured in Wireshark (22 = open, 23 = closed)

Port 22 is open, while port 23 is closed, but both reply with a RST packet when an ACK packet is sent. This shows that both ports are not filtered by any firewalls.

Pro: maps out firewall rulesets
Con: cannot determine if the port is open or closed

Idle Scan (-sI)

Syntax: nmap -sI <zombie-ip> <target-ip> [-p <ports>]
This is the most interesting — yet the most complex — scan of all. As you can see from the syntax, we require a “zombie” in order to perform an idle scan. In a nutshell, Nmap will attempt to leverage an idle host to indirectly launch a port scan, therefore hiding our IP address from the target. It does this using the difference in increments of the IP ID of the zombie.

To understand how Nmap achieves this in understandable detail, please look at figures 5.65.7 and 5.8 in https://nmap.org/book/idlescan.html.

Pro: masks our true IP address
Con: possibility of false positives (due to zombie host not being idle)

Further Digging:

If you want to know more about these scan types, and other scan types Nmap has to offer, take a look at: