HTTP Verb Tampering

Photo by Christopher Gower on Unsplash

HTTP is the protocol that lets applications respond to requests and retrieve data. An HTTP verb is one of several actions the application can use when querying the server. Standard HTTP verbs include:

  • GET: retrieves data from specified source
  • HEAD: requests preview of specified resource
  • POST: submits entity to specified resource, such as editing data
  • PUT: transmits new data to the specified resource replacing the old information
  • DELETE: deletes the specified resource entirely

Most web applications use HTTP verbs to authenticate users and manage access privileges. However, malicious actors can bypass authentication and access controls to protect privileged information.

December 2, 2023 by Application Security 0

Attack Surface: How can I reduce the attack surface?

Photo by Azamat E on Unsplash

There are various ways to decrease the attack surface. Let’s take a look at some of the more widely used techniques.

The digital side

The easiest target to attack is the digital attack surface. Let’s explore effective strategies to reduce the attack surface.

Less code, less software attack surface

When you reduce the code you’re running in your desktop, server, or cloud instance, you’re reducing the possibilities for entry points to be discovered and later exploited. Turn off, disable, or remove unnecessary software features, and simplify your code. Fewer codes also mean fewer software bugs and vulnerabilities; at the end of the day, that equals fewer security risks overall.

Remove unnecessary OS software and services.

Cleaning the OS includes removing unnecessary functions, applications, and system tools. Do you need a printing service running if you don’t use a printer? What about that MYSQL server running on the 3306 port? Do you need it if you don’t host any databases? And is Adobe Suite required if you don’t work with any PDF files? Install only the strictly necessary applications for your employees’ daily work, and turn off all unused protocols or services. The same advice goes for servers.

Scan your network ports.

Scanning the open ports in your public IP addresses is often the first thing attackers do when performing infosec reconnaissance on any target.

Luckily, there are many ways for you to stay one step ahead of your attackers. And your best bet is to begin auditing your network ports before they do. In our previous article about most scanned ports, we showed a quick way to get famous using the almighty Nmap command.

While using the Nmap top-ports option helps audit your port exposure, this activity can be done using different port scanners such as Unicornscan, Angry IP Scanner, or Netcat.

Analyze your SSL certificates.

People often see SSL certificates as a way to prove a website is secure, but that can be a big mistake.

How hardened are your SSL certificates? Are you keeping your SSL chains complete and well-secured? Are you using strong cipher suites? These are fundamental questions that all developers, system administrators, and technical managers should ask themselves more often. Additional information can be found in our article: Is SSL a real sign of security?

But SSL security doesn’t end up in your hardening, chain, and overall security score. You also need to consider the data you’re exposing to the public.

Have you ever thought about your SSL certificate expiration and validity? Your attack surface includes all your SSL certificates—valid, active, and expired ones.

Of course, the bad guys can explore such public information. So, remember that while SSL certificates are suitable for encrypting your information…not having a thorough audit or control over them can lead to some of your worst nightmares.

Segmentation your network

Keeping all your assets within a single network is often one of the biggest mistakes you can make. Splitting and segmenting your network is one of the easiest ways to reduce your attack surface.

This will help increase your network barriers and, at the same time, help you gain better and more effective server or desktop controls over all machines connected to the network.

Audit your software, network, and traffic.

Auditing your software is one of the oldest known tactics for reducing your attack surface. This will help detect misconfigurations and outdated software, test the security system, and keep users’ activity under control.

Analyzing the network, protocols, OS services, and current and past traffic over the network is a great way to detect factors that could expose your attack surface even more.

Log analysis plays a critical role in reducing your attack surface. Also, running scheduled audits on overlooked services (such as the DNS service) can help keep your exposure under control, as we covered in our previous article: Why should I perform a DNS audit?

The human side

The physical attack surface involves our world, making its most significant component none other than the human being.

As we’ve said before, company staff is often one of the weakest links in the cybersecurity chain of your online business.

Let’s see what can be done to avoid exposing your physical attack surface as much as possible:

Train all your employees to avoid getting tricked by social engineering calls or phishing emails. These are two of the most common ways to sabotage networks, routers, and other physical hardware, most of the time allowed by your human capital. 

While nothing can prevent rogue employees from stealing sensitive information about your company (including email or user logins), human resource and hiring departments do have psychological tests in hand for screening applicants. These tests may reveal the true nature (including many unconscious aspects) of the people in line to work with your team.

Teaching your employees correct policies concerning using unknown and unauthorized devices in the office can also help reduce baiting attacks. 

There are more social engineering techniques we’ll explore in future posts. Fortunately, they all rely on following company-based security practices and constant employee education.

November 15, 2023 by Cyber Security 0

Attack Surface: What is an attack surface?

Photo by Bernd 📷 Dittrich on Unsplash

What does “attack surface” mean? I see the attack surface as the entire network and software environment exposed to remote or local attacks. For others, it’s the sum of compromised points—although that’s not the attack surface, but the attack vectors.

An attack surface refers to all the ways attackers can exploit your apps. This includes software, operating systems, network services and protocols, domain names, and SSL certificates.

A classic example to help illustrate the concept of attack surface is your business’s physical office. What’s the attack surface of your local office?

The answer is simple: doors, windows, safe boxes, etc. What about your home? Even simpler: front and back doors, windows, garage doors, climbable trees or tables, etc.

The difference between detecting a breach in your home and a violation in your company’s online attack surface can be characterized by the size of the area and its inclusion of multiple complex regions to explore.

You’d clearly notice if someone had broken a window or forced open the door in your home. It’s even easier to have a home alarm system that notifies you immediately.

However, due to the extensive network, software, protocols, and services running within an online company, detecting what part of the attack surface was the origin of the breach or intrusion can be tricky, even with a solid IDS in place, application firewalls, and notification alerts. Most of the time, it may pass unnoticed.

November 7, 2023 by Cyber Security 0

Hardening Your HTTP Security Headers Part 2

Photo by Maik Jonietz on Unsplash

4. X-Frame-Options

The x-frame-options header provides click jacking protection by not allowing iframes to load on your website. It is supported by IE 8+, Chrome 4.1+, Firefox 3.6.9+, Opera 10.5+, Safari 4+. Here is an example of what the header looks like:

x-frame-options: SAMEORIGIN

Enable in Nginx

add_header x-frame-options "SAMEORIGIN" always;

Enable in Apache

header always set x-frame-options "SAMEORIGIN"

5. Expect-CT

The expect-ct header prevents miss used certificates from being used by allowing websites to report and optionally enforce Certificate Transparency requirements. When this header is enabled the website is requesting the browser to verify whether or not the certificate appears in the public CT logs. Here is an example of what the header looks like:

expect-ct: max-age=604800, enforce, report-uri=”https://www.example.com/report”

Enable in Nginx

add_header expect-ct "max-age=604800, enforce, report-uri='https://www.example.com/report' always;

Enable in Apache

header always set expect-ct "max-age=604800, enforce, report-uri="https://www.example.com/report"

6. X-Content-Type-Options

The x-content-type-options header prevents Internet Explorer and Google Chrome from sniffing a response away from the declared content-type. This helps reduce the danger of drive-by downloads and helps treat the content the right way. Here is an example of what the header looks like:

x-content-type-options: nosniff

Enable in Nginx

add_header x-content-type-options "nosniff" always;

Enable in Apache

header always set x-content-type-options "nosniff"

7. Feature-Policy

The feature-policy header grants the ability to allow or deny browser features, whether in its own frame or content within an inline frame element (<iframe>). Here is an example of what the header looks like:

feature-policy: autoplay 'none'; camera 'none'

Enable in Nginx

add_header feature-policy "autoplay 'none'; camera 'none'" always;

Enable in Apache

header always set feature-policy "autoplay 'none'; camera 'none'"

October 29, 2023 by Application Security 0

Hardening Your HTTP Security Headers Part 1

Photo by Markus Spiske on Unsplash

There are a lot of things to consider when securing your website or web application, but a good place to start is to explore your HTTP security headers and ensure you are keeping up with best practices. In many cases, they are very easy to implement and only require a slight web server configuration change. HTTP security headers provide yet another layer of security by helping to mitigate attacks and security vulnerabilities. In this post, we will explore some of them to help you better understand their purpose and how to implement them.

What Are HTTP Security Headers?

Whenever a browser requests a page from a web server, the server responds with the content along with HTTP response headers. Some of these headers contain content metadata such as the content-encoding, cache-control, status error codes, etc.

Along with these are also HTTP security headers that tell your browser how to behave when handling your website’s content. For example, by using the strict-transport-security you can force the browser to communicate solely over HTTPS. There are six different HTTP security headers that we will explore below (in no particular order) that you should be aware of and we recommend implementing if possible.

1. Content Security Policy

The content-security-policy the header provides an additional layer of security. This policy helps prevent attacks such as Cross-Site Scripting (XSS) and other code injection attacks by defining content sources that are approved and thus allowing the browser to load them.

All major browsers currently offer full or partial support for content security policy. And it won’t break the delivery of the content if it does happen to be delivered to an older browser, it will simply not be executed.

There are many directives which you can use with content security policy. This example below allows scripts from both the current domain (defined by ‘self’) as well as google-analytics.com.

content-security-policy: script-src ‘self’ https://www.google-analytics.com

To explore all of the directives, and to see implementation on Nginx and Apache, make sure to check out our in-depth post on Content Security Policy.

2. X-XSS-Protection

The x-xss-protection the header is designed to enable the cross-site scripting (XSS) filter built into modern web browsers. This is usually enabled by default, but using it will enforce it. It is supported by Internet Explorer 8+, Chrome, and Safari. Here is an example of what the header looks like:

x-xss-protection: 1; mode=block

Enable in Nginx

add_header x-xss-protection “1; mode=block” always;

Enable in Apache

header always set x-xss-protection “1; mode=block”

3. HTTP Strict Transport Security (HSTS)

The strict-transport-security header is a security enhancement that restricts web browsers to access web servers solely over HTTPS. This ensures the connection cannot be established through an insecure HTTP connection which could be susceptible to attacks.

All major modern browsers currently support HTTP strict transport security except for Opera Mini and versions previous of Internet Explorer.

Here is an example of what the header looks like: You can include the max-age, subdomains, and preload.

strict-transport-security: max-age=31536000; includeSubDomains; preload

To read more about this header and see implementation on Nginx and Apache, make sure to check out our in-depth post on HTTP Strict Transport Security.

October 15, 2023 by Application Security 0

What is DNS Spoofing?

Photo by Lars Kienle on Unsplash

DNS spoofing, or DNS cache poisoning, is a phishing and cyber attack where false Domain Name System (DNS) information is introduced into a DNS resolver’s cache. This causes DNS queries to return an incorrect response, which commonly redirects users from a legitimate website to a malicious website designed to steal sensitive information or install malware.

There are several reasons why DNS spoofing is possible, but the principal problem is DNS was built in the 1980s when the Internet was much smaller, and security was not a primary concern. There is no in-built way for DNS resolvers to verify the validity of the data they store, and incorrect DNS information can remain until the time to live (TTL) expires or is manually updated.

How Do Attackers Poison DNS Caches?

DNS poisoning or DNS spoofing attacks work by impersonating DNS nameservers, making a request to a DNS resolver, and then forging the reply when the DNS resolver queries a nameserver. This is possible because DNS uses UDP, an unencrypted protocol, which makes it easy to intercept traffic with spoofing. DNS servers do not validate the IP addresses they are directing traffic to.

There are two common methods for poisoning DNS caches:

Man in the middle attack: The interception of communication between users and a DNS server to route users to a different or malicious IP address. In this situation, the attacker sits between the computer’s stub resolver and the recursive resolver, sending back a fake DNS result.

DNS server compromise: This type of attack occurs when an attacker gains direct access to the DNS server of a domain, generally through spear phishing or whaling, and updates the DNS entries to point to a malicious website. This type of attack is also known as DNS hijacking.

This works because, unlike TCP, which relies on both communicating parties performing a ‘handshake’ to initiate communication and verify the identity of devices, DNS requests and responses rely on UDP or User Datagram Protocol. With UDP, there is no guarantee that a connection is open, that the recipient is ready to receive, or that the sender is who they say they are. This leaves UDP communications vulnerable to MITM attacks; an attacker can send a message via UDP, pretending that it is a legitimate nameserver by forging header data. If the receiving DNS resolver accepts the fake response and caches, which can happen as there is no way to verify if the information is accurate and comes from a legitimate source. With that said, DNS spoofing attacks are not easy to pull off as the DNS resolver queries the authoritative nameserver giving attackers only a few milliseconds to fake the response before the real response arrives.

When are DNS Spoofing Attacks Successful?

For a DNS spoofing attack to be successful, attackers either need to know or guess:

Which DNS queries are not cached by the targeted DNS resolver so that the resolver will query the authoritative name server what port the DNS resolver uses, which was easy in the past but has since become much more difficult as DNS resolvers rotate their open ports to mitigate DNS spoofing The request ID number which authoritative nameserver the DNS resolver will query.

Furthermore, these malicious websites are often used to install computer worms, ransomware, and spyware on the user’s computer, giving the perpetrator long-term access.

How to Mitigate DNS Spoofing

The Domain Name System Security Extensions (DNSSEC or DNS Security Extensions) is a set of Internet Engineering Task Force (IETF) specifications designed to secure certain kinds of information the DNS provides. DNSSEC provides DNS resolvers origin authentication of DNS data, authenticated denial of existence, and data integrity but not availability or confidentiality.

Like TLS/SSL, DNSSEC uses public-key cryptography to verify and authenticate DNS data.

When DNSSEC is used, each answer to a DNS request contains an RRSIG DNS record and the requested record type. The RRSIG record is a digital signature of the requested DNS data. The digital signature is verified by locating the correct public key in the DNSKEY. The NSEC and NSEC3 records are used to provide cryptographic evidence of the non-existence of any request. This is also known as authenticated denial of existence.

The delegation signer (DS) is used to authenticate DNSKEYs by using a chain of trust. NSEC and NSEC3 also serve the purpose of providing robust resistance against spoofing.

The chain of trust starts with a set of verified public keys for the DNS root zone, the trusted third party. Domain owners generate their own public key/private key pair and upload them using their domain-name registrar’s DNS control panel, which pushes the keys via secDNS to the zone operator (for example, Verisign for the com zone), who signs and publishes them in the DNS.

This prevents resolvers from caching forged or manipulated DNS data and prevents cache poisoning.

In short, DNSSEC provides two security features to DNS:

Data origin authentication: This allows a resolver to cryptographically verify data from the zone requested.Data integrity protection: This allows a resolver to know that the data hasn’t been modified in transit and was originally signed by the zone owner’s private key.

These two security features all any recursive resolver to look up data in the zone and retrieve the zone’s public key, which is then used to validate the authenticity of provided DNS data. Resolvers then confirm the digital signature received matches what they expect and return it to the end-user. If the signature is not valid, the resolver assumes a cyber attack, discards the data, and returns an error.

While the primary concern of DNSSEC is to prevent the cyber threat of DNS spoofing, resulting in users being directed to the wrong place, DNSSEC provides the additional benefit of protecting text records (TXT) and mail records (MX). DNSSEC has also been used to bootstrap other cyber security systems that publish cryptographic certificates stored in DNS, such as Certificate records, SSH fingerprints, IPSec public keys, and TLS Trust Anchors.

That said, DNSSEC, unlike SSL certificates, does not provide confidentiality of data. DNSSEC responses are authenticated but not encrypted. Nor does DNSSEC protect against cyber attacks like distributed denial of service attacks (DDoS attacks).

DNSSEC also has several potential downsides, including:

Lack of data confidentiality: While DNSSEC authenticates, it does. not encode DNS responses. This means that perpetrators can still listen in on traffic and use this data for more sophisticated attacks; this is why SSL certificates are such an important part of Internet security. Deployment complexity: DNSSEC is easily misconfigured, which can cause servers to lose their security benefits or even deny access to the website altogether. No widespread adoption: While DNSSEC was published in 2005, it has not yet become mainstream, leaving any DNS records vulnerable to attacks.

Beyond DNSSEC, there are other ways you can prevent DNS spoofing:

Active monitoring: DNS data should be continuously monitored for changes, such as the appearance of a new external host, that could indicate compromise.

Patching: Like anything, DNS servers and software can be vulnerable to exploits and zero-day vulnerabilities. Ensure whoever is hosting your DNS records is meticulous about vulnerability management and attack surface management.

DNS updates Newer versions of DNS use port randomization and cryptographically secure transaction IDs to prevent DNS attackers and ensure your servers are up-to-date.

Password policies: Ensure you use strong passwords and, ideally, two-factor authentication for the account that manages your DNS records. And don’t forget about changing default passwords on network equipment, such as routers, which can put every device and user in danger if compromised. Read our guides on password security and network security for more information.

Invest in cybersecurity awareness training: Remember that many DNS spoofing attacks are either the result of or aim to initiate some phishing attack. Educate your staff about what to look for in phishing campaigns.

September 29, 2023 by Network Security 0

How to Detect Security Incidents Targeting Web Applications
Photo by Shamin Haky on Unsplash

The two most popular incident response frameworks come from NIST and SANS. While they differ in how they group and name the phases of incident response, both follow the same basic process. Based on this, here are six steps for incident handling in web application security: Prepare, Detect, Contain, Address, Recover, and Learn.

Step 1: Prepare

Preparation is by far the most essential stage of incident response. To secure your web assets, you first need to know what assets you have – and surprisingly, many organizations don’t even know that. Similarly, to ensure data security, you need to know your data, where it resides, who should have access to it, and how critical it is to your business.

Next, you need some kind of risk assessment process so you know what security events and impacts you are preparing for. Depending on your policies and requirements, this could involve formal threat modeling or a more informal approach to threat intelligence and identifying the most likely attack vectors.

In the preparation stage, you will likely identify weaknesses or blind spots you must address. For example, if you use a tool like Netsparker to run asset discovery followed by a vulnerability scan, you may find forgotten or unmaintained websites vulnerable to attack. These issues must be addressed to reduce your attack surface and close all the gaps, so you might call this Step 0: Prevent.

Whatever you put in your incident response plan, you need someone to implement it when things go wrong. Your incident response (IR) team will often simply be your IT security team, though large organizations may have a dedicated computer security incident response team (CSIRT). In either case, you must have specific team members on call and ready to follow established procedures.

Step 2: Detect

Web application attacks and data breaches are often only detected after many days or even months – or not detected at all, especially if they have no direct impact on operations. Careful logging and monitoring at the application level can help detect suspicious activity, such as repeated access attempts or unexpected user accounts being created. You can use a security information and event management (SIEM) solution to coordinate these monitoring efforts. Regular security testing using an accurate and up-to-date web vulnerability scanner is also vital to prevent attacks and find new vulnerabilities that attackers could already have exploited.

Step 3: Contain

After a web security incident is detected, your IR team needs to triage it and decide on the best action to minimize short-term impact and prevent minor issues from escalating into full-blown incidents. For example, suppose you detect a critical vulnerability in one of your business applications being actively exploited. In that case, the containment phase might involve setting up your web application firewall (WAF) to block this attack and prevent further damage. Advanced vulnerability scanners like Netsparker can even integrate with popular WAF platforms automatically.

Step 4: Address

Once the immediate threat is under control, you must fix or permanently address the issue. Continuing the example of your critical vulnerability, your security team would take the vulnerability report and create a fixed ticket for developers after deploying a WAF rule to block attacks in the containment phase. In the case of Netsparker, this process can also be automated to streamline communication and minimize the response time.

Recent global cyberattacks have served as a reminder that plugging security holes is often the easiest part. Advanced threat actors don’t do hit-and-run attacks but rather infiltrate target systems to maintain a stealthy and persistent presence. Eliminating the entry point starts a long and arduous process where your IT security and administrators check all potentially affected systems for malicious code, such as web shells, and then clean or rebuild them.

If you’ve had a data breach, you may also have legal obligations to take care of, such as GDPR-mandated notifications. Depending on the type of data and your jurisdiction and industry, you might need to report the incident to law enforcement or the relevant regulatory bodies and update this notification as more information becomes available.

Step 5: Recover

While most web application security incidents won’t require a full disaster recovery process, you need to have incident recovery procedures in place for every eventuality and every level of the application stack. In IT security, everything is connected, so a web application breach could be just one part of a broader attack that affects other systems or threatens business continuity. Regardless of the incident, the overriding goal of your recovery process should be to restore regular service while minimizing damage and disruption to business operations.

Step 6: Learn

Once the fire is out, you can move to post-incident activities such as a post-mortem or root cause analysis. This phase is probably the most important for improving long-term security since many web attacks are performed by reusing and adapting existing techniques. For example, fixing only a specific injection vulnerability without making the relevant part of the application code more secure may allow attackers to modify the attack payload slightly and breach the application again. By analyzing each incident and drawing the right lessons, you can return to step 1 – and be better prepared for the next attack.

September 8, 2023 by Application Security 0

What is a Seedbox?

Photo by Taylor Vick on Unsplash

A seedbox is a dedicated, high-speed server for downloading and uploading files. Most people rent seedboxes to achieve very fast torrent or Usenet transfers. Typically, you will see speeds from 100Mbps (8 MB/s) to 10Gbps (1250 MB/s) on a seedbox.

A seedbox also allows you to avoid ISP throttling and bypass eavesdroppers like the RIAA or MPAA.

Today, there are many seedbox providers — most are run by individuals or small companies. These seedboxes have some of the best feedback from customers:

How To Use A Seedbox

Generally, seedboxes are set up so that you can install Usenet and torrent applications quite easily.

Once the files are downloaded to the seedbox, they can then be downloaded to your computer via HTTP, FTP, SFTP, or rsync protocols. You can also directly stream the media from the seedbox with an application like Plex.

Some seedboxes may provide VNC connection or remote desktop protocol on some Windows-based machines. This allows many popular clients to be run remotely.

Seedbox Providers

These are my recommended seedbox providers:

  • RapidSeedbox offers root access and many apps available as “one click installs” including Plex and OpenVPN. Accepts bitcoin, 14 day refund policy. €15 euro ($18 USD) month-to-month.
  • DediSeedbox also offers OpenVPN and Plex as a “one click” install. Root access to your own VPS. Good disk space allowances (1TB with the $15 per month plan).
August 18, 2023 by Privacy 0

What Is a Man-in-the-Middle Attack

Photo by Stephen Phillips – Hostreviews.co.uk on Unsplash

A man-in-the-middle attack, often abbreviated as an MITM attack, is a type of cyber assault in which an unauthorized individual interposes themselves in the communication flow between two parties who assume they are engaging in direct communication. In this scenario, the attacker gains the ability to intercept, eavesdrop on, and potentially manipulate the content of the communication taking place. Man-in-the-middle attacks pose a significant threat as they allow for clandestine surveillance and potential tampering with communications across various contexts, such as interactions between individuals, clients, and servers, and even secure connections like HTTPS and other SSL/TLS protocols, as well as Wi-Fi network connections, among others.

Here is how a Man-in-the-middle attack works.

Picture a scenario where you and a colleague are engaged in a conversation through a secure messaging platform. In this situation, an adversary with malicious intent aims to intercept your exchange, clandestinely monitor it, and insert fabricated messages into the conversation, making it appear that these false messages are coming from you to your colleague. This form of cyber attack illustrates the peril of a man-in-the-middle assault, where the attacker attempts to undermine the integrity and confidentiality of your communication.

Initially, you request your colleague’s public key to establish secure communication. If your colleague sends her public key, but an attacker manages to intercept it, a man-in-the-middle attack becomes possible. The attacker sends you a fabricated message skillfully designed to mimic your colleague’s communication. However, this message contains the attacker’s public key instead of your colleague’s legitimate one. Thinking you are using your colleague’s public key, you encrypt your message and unknowingly employ the attacker’s key to secure it. Subsequently, you send this encrypted message back to what you believe is your “colleague.”The attacker, once again, intercepts the message, decrypts it using their private key, manipulates the content, and then re-encrypts it using the public key they initially intercepted from your colleague, who had intended to send it to you. As your colleague receives and examines the encrypted message, she is under the impression that it originated from you, unaware of the attacker’s meddling.

August 16, 2023 by Cyber Security 0

Bypassing Firewalls Using Nmap

Photo by Sigmund on Unsplash

Nowadays, almost every system is protected by firewalls or Intrusion Detection Systems (IDS). Nmap provides various ways to bypass these firewalls or IDS to perform port scans on a system.

TCP ACK Scan

nmap -sA x.x.x.x

How it works…The filtered and unfiltered port scan results depend on whether the firewall is stateful or stateless. A stateful firewall checks whether an incoming ACK packet is part of an existing connection. It blocks it if the packets are not part of any requested connection. Hence, the port will show up as filtered during a scan. Whereas, in the case of a stateless firewall, it will not block the ACK packets,

TCP Window Scan

nmap -sW x.x.x.x

Idle scan

Idle scanning is an advanced technique where no packets sent to the target can be traced back to the attacker’s machine. It requires a zombie host to be specified.

nmap -sI zombiehost.com domain.com

Idle scan works based on a predictable IPID or an IP fragmentation ID of the zombie host. First, the IPID of the zombie host is checked, and then a connection request is spoofed from that host to the target host. If the port is open, an acknowledgment is sent back to the zombie host, which resets (RST) the connection as it has no history of opening such a connection. Next, the attacker checks the IPID on the zombie again; if it has changed by one step, it implies an RST was received from the target. But if the IPID has changed by two steps, it means a packet was received by the zombie host from the target host, and there was an RST on the zombie host, which implies that the port is open.

July 29, 2023 by Network Security 0

Recent Comments

No comments to show.