PL Class #2 – Scouting

CDIS UNICV © Tiago Cruz ([email protected])

Scouting the network

2
Our objective

A scouting procedure shares a lot of similarities with

the preliminary steps for a pentesting session,
despite the obvious differences, especially in terms
of the objective.

§ You must plan before executing

§ Gather as much intelligence as possible from
out-of-band sources
§ Strive to be invisible

1/9/23 3
Kali VMs

Access your Kali Linux VMs via the Vmware

console, check the IP address that was
assigned for the the 10.254.0.x network.

Make sure you have activated the SSH service

and open a ssh session.

sudo systemctl enable ssh

sudo systemctl start ssh

4
 Pre-flight check
You don’t want to give up your presence, so you disable ARP replies
on non-local interfaces (adjust the eth1 to your specific interface)
and mitigate
root@kali:~# sudo -i
root@kali:~# echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_ignore
root@kali:~# echo 2 > /proc/sys/net/ipv4/conf/eth1/arp_announce
root@kali:~# echo 0 > /proc/sys/net/ipv4/conf/eth1/arp_notify

Just for informational purposes, we don’t want this in CDIS:

To make this settings persistent, you could edit the
/etc/sysctl.conf file and add these two lines:
net.ipv4.conf.eth1.arp_ignore = 1
net.ipv4.conf.eth1.arp_announce = 2
net.ipv4.conf.eth1.arp_notify = 0
5
Why?
arp_notify=0
Define mode for notification of address and device changes.
0 - (default): do nothing.
arp_ignore=1
Reply only if the target IP address is local address configured on the incoming
interface.
arp_announce=2
Always use the best local IP address corresponding to the destination IP address
as the source IP address for the ARP request. In this mode, the source IP address
of the IP packet is ignored and an attempt is to select a native address that can
communicate with the destination IP address. The first is to select all network
interfaces The subnet contains the native IP address of the destination IP
address. If there is no appropriate address, the current network interface or
other network interface that is likely to receive the ARP response is selected to
send the ARP request, and the IP address of the network interface card that
sends the ARP request is set to the source IP of the ARP request.

6
Also
You could also disable ARP altogether in an interface:
u ip link set dev eth1 arp off

Arptables could also provide fine-grained control:

u arptables -F
u arptables -A INPUT -d $IP -j DROP
(drops incoming ARP requests for local IP)
u arptables -A INPUT -i eth1 -j DROP
(drops incoming ARP requests on interface)
u arptables -A OUTPUT -s $IP -j mangle --mangle-ip-s $RIP
(mangle the source IP of outgoing ARP request from $IP to $RIP)
u arptables -A OUTPUT -o eth1 -j DROP
(drops outgoing ARP requests on interface)

7
Pre-flight check
§ It is recommended for you to use a separate
network interface for pentesting tasks.

§ You can start by assigning it a dummy IP address,

outside the scope of the network range you are
going to analyze.

§ Prior to configuring an IP address, it is advisable

for you to scout the IP ranges circulating on the
network segment, eventually using a tool such as
tshark, wireshark or tcpdump.

1/9/23 8
 Pre-flight check
(example of tcpdump on eth1)

§ Do you know what are the ARP packets?

§ Do you know what are the STP packets?
§ Discovering/understanding the rest will be part of your assignment
9
Pre-flight check
Just for informational purposes, don’t do this in the testbed:

Eventually, we could decide to configure the eth1 interface with the 1.1.1.1
address:
u ifconfig eth1 1.1.1.1 netmask 255.255.255.254

ARP replies for non-local ranges are disabled, so our host will not give up its
presence by announcing local source IPs or answering ARP queries.

An extreme measure might involve completely disabling ARP on the interface:

u echo 8 > /proc/sys/net/ipv4/conf/eth1/arp_ignore

10
Step 1: range recognition
§ You want to enumerate the devices present on
the address range.
§ Which one? A trace analysis might help.

§ Several tools can be used for this purpose

(nping, arpping, nmap, etc).
§ Bear in mind the recommendations from the last
class regarding the scan rate.

11
Step 1: range recognition
Some examples
Using arp-scan:

u arp-scan --interface=eth1 172.27.224.45-172.27.224.253 \

--arpspa 172.27.224.80 -v --interval=250
(182.27.224.80 is a self-assigned IP address)

This command executes an ARP scan on the eth0 interface, using a spoofed IP
address, by issuing ARP queries for an IP range. Throttling is ensured by means of
the –interval option (in milliseconds).
(for testing in this class, you can adjust the interval to 50 to make
things a little faster, but in real systems you should be patient)

What do you see ?

1/9/23 12
Step 1: range recognition
Some examples

ATTENTION !
For the next ones to work you’ll need
a valid network IP address for the testbed NIC.

Reserve yours using the group registration spreadsheet

available at the URL: https://cdis.page.link/sync

only use the range 172.27.224.20-60, for instance:

21 for group 1
22 for group 2
23 for group 3
…
32 for group 4
1/9/23 13
 Step 1: range recognition
Some examples
Using nmap:
u route add –net 172.27.224.0/24 dev eth1
u nmap --send-eth -e eth1 -sn -n --scan-delay 1 172.27.224.45-253

This command executes a network range scan on the eth1 interface,

using a spoofed IP address, by issuing ICMP queries (-sn).
Throttling is ensured by means of the –scan-delay option (in seconds).
DNS queries are disabled.
(suggestion for homework: check also the –T profiles).

What do you see ?

1/9/23 14
Output arp-scan

nmap

1/9/23 15
A quick detour…
nmap scan stages (that you may explore in your assignment)

1. Script pre-scanning. The Nmap Scripting Engine (NSE) uses a collection

of special-purpose scripts to gain more information about remote
systems. NSE is not executed unless you request it. This phase is for
scripts which only have to be run once per Nmap execution rather than
running separately against individual targets.
2. Target enumeration. In this phase, Nmap researches the host specifiers
provided by the user, which may be a combination of host DNS names,
IP addresses, CIDR network notations, and more. Nmap resolves these
specifiers into a list of IPv4 or IPv6 addresses for scanning. This phase
cannot be skipped since it is essential for further scanning, but you can
simplify the processing by passing just IP addresses, so Nmap doesn't
have to do forward resolution
3. Host discovery (ping scanning). Network scans usually begin by
discovering which targets on the network are online and thus worth
deeper investigation. This process is called host discovery or ping
scanning. This phase is run by default, though you can skip it (simply
assume all target IPs are online) using the -Pn (no ping) option.

Source: https://nmap.org/book/nmap-phases.html
16
A quick detour…
nmap scan stages (that you may explore in your assignment)

4. Reverse-DNS resolution. Once Nmap has determined which hosts to

scan, it looks up the reverse-DNS names of all hosts found online by
the ping scan. Sometimes a host's name provides clues to its function,
and names make reports more readable than providing only IP
numbers. This step may be skipped with the -n (no resolution)
option, or expanded to cover all target IPs (even down ones) with -
R (resolve all).
5. Port scanning. This is Nmap's core operation. Probes are sent, and the
responses (or non-responses) to those probes are used to classify
remote ports into states such as open, closed, or filtered. Port
scanning is performed by default, though you can skip it with the -
sn option.
6. Version detection. If any ports are found to be open, Nmap may be
able to determine what server software is running on the remote
system. It does this by sending a variety of probes to the open ports
and matching any responses against a database of known service
signatures.
17
A quick detour…
nmap scan stages (that you may explore in your assignment)

7. OS detection. If requested with the -O option, Nmap proceeds to

OS detection. Different operating systems implement network
standards in subtly different ways. By measuring these differences
it is often possible to determine the operating system running on a
remote host.
8. Traceroute. Nmap contains an optimized traceroute
implementation, enabled by the --traceroute option. It can find the
network routes to many hosts in parallel, using the best available
probe packets as determined by Nmap's previous discovery phases.
Traceroute usually involves another round of reverse-DNS resolution
for the intermediate hosts.
9. Script scanning. Most Nmap Scripting Engine (NSE) scripts run
during this main script scanning phase, rather than the prescan and
postscan phases. NSE is powered by the Lua programming language
and a standard library designed for network information gathering.
Scripts running during this phase generally run once for each target
host and port number that they interact with.
18
A quick detour…
nmap scan stages (that you may explore in your assignment)

10. Output. Finally, Nmap collects all the information it has gathered
and writes it to the screen or to a file. Nmap can write output in
several formats.
11. Script post-scanning. After Nmap has completed its scanning and
normal output, scripts in this phase can process results and
deliver final reports and statistics.
Nmap offers many options for controlling which of these phases are
run. For scans of large networks, each phase is repeated many times
since Nmap deals with the hosts in smaller groups. It scans each
group completely and outputs those results, then moves on to the
next batch of hosts.

19
Step 2: target profiling
Nmap Output for 172.27.224.250

For more sophisticated scans you should assign a valid IP address to the
interface. Once again, nmap may be helpful.
TCP SYN SCAN
nmap --send-eth -e eth1 -sS -n 172.27.224.250 \
-–scan-delay 1 –p 1-1024 –Pn --disable-arp-ping

20
Step 2: target profiling
Nmap Output for 172.27.224.250

For more sophisticated scans you should assign a valid IP address to the
interface. Once again, nmap may be helpful.
TCP SYN SCAN
nmap --send-eth -e eth1 -sS -n 172.27.224.250 \
-–scan-delay 1 –p 1-1024 –Pn --disable-arp-ping

This is
probably a
PLC…

1/9/23 21
Step 2: target profiling
Once you get information about the hosts on the network
you’ll probably want to profile them.
Nmap is one of the best tools for this:
TCP FIN (FRAG) SCAN
nmap --send-eth -e eth1 -sF -f -n 172.27.224.250 \
-–scan-delay 1 –p 1-1024 –Pn --disable-arp-ping
SERVICE Versioning (verbose)
nmap --send-eth -e eth1 -sV -f -n 172.27.224.250 -v \
-p 1-1024 -Pn --disable-arp-ping –-scan-delay 1
UDP SCAN
nmap --send-eth -e eth1 -sU -n 172.27.224.250 \
–-scan-delay 1 –p 1-2014 –Pn --disable-arp-ping
(WARNING: Avoid using this one)
1/9/23 22
About UDP (and other) scans

At a first glance, UDP scans do not seem to pose a problem. But, in

fact, the specific nature of the procedure is quite sensitive.

The main issue has to do with the way nmap probes UDP ports, by
using null request payloads (for fingerprinting operations it can be
worse, because even malformed packets may be used).

For pretty much the same reasons that led to the unreliability of
some TCP/IP stack or service implementations, several developers
just didn’t care about sanitizing and/or validating protocol requests…

For similar reasons, tools such as Nessus should be used with

restraint…

1/9/23 23
Step 2: target profiling
Nmap Output for 172.27.224.250

FIN Scan

Version Scan

UDP Scan

1/9/23 24
 What did we find ?

Most likely a Schneider Electric PLC. Well, to confirm our

suspicions we can resort to a custom nmap script:
§ https://github.com/digitalbond/Redpoint
(check the modicon-info.nse script)
Download the script:
wget https://raw.githubusercontent.com/digitalbond/
Redpoint/master/modicon-info.nse

1/9/23 25

Some hints: http://www.modbus.org/devices.php?wireless=both&all=Y

 What did we find ?

And move it to the nmap script folder:

§ mv modicon-info.nse /usr/share/nmap/scripts
§ nmap -p 502 --script modicon-info.nse –Pn -sV <host>

This one also requires a valid network IP

address for the testbed NIC.

1/9/23 26

Some hints: http://www.modbus.org/devices.php?wireless=both&all=Y

Our subject

1/9/23 27
Let the fun begin
For an in-depth analysis of our subject we are going to use the smod Modbus
pentesting framework:
https://github.com/oliverkko/smod

Download https://github.com/oliverkko/smod/archive/master.zip
Unzip the file.
Execute the following commands (in case you don’t have pip2, execute
apt-get install python-pip):
§ pip2 install crypto
§ pip2 install scapy

Execute the tool:

§ cd smod-master
§ python2 smod.py
1/9/23 28
Let the fun begin
Framework features

1/9/23 29
Let the fun begin
Which are the valid FCs for this device ?

1/9/23 30
 Let the fun begin
Which are the valid UIDs for this device ?

1/9/23 31

Note: some versions may report only one UID, but the entire UID range is accepted.
Let the fun begin
Let’s read some coil registers:

1/9/23 32
Next steps - Homework

You are going to finish the reconnaissance

procedure:
§ Check for the remaining devices.
§ Profile the devices you might find.
§ You can use any tools you might want to try.
§ Document everything in your personal notes

Be prepared to present your findings

in the next class ! 1/9/23 33