Tag Archives: Technology

League of Legends Live: A Concert Experience at 2017 Worlds Countdown

League of Legends Live: A Concert Experience at 2017 Worlds Countdown

https://clips.twitch.tv/embed?clip=AverageStormyOilBlargNaut&autoplay=false&tt_medium=clips_embed

 

Advertisements

Astronomy Picture of the Day – Eclipsosaurus Rex

See Explanation.  Clicking on the picture will download
 the highest resolution version available.

Eclipsosaurus Rex 
Image Credit & CopyrightFred Espenak (MrEclipse.com)Explanation: We live in an era where total solar eclipses are possible because at times the apparent size of the Moon can just cover the disk of the Sun. But the Moon is slowly moving away from planet Earth. Its distance is measured to increase about 1.5 inches (3.8 centimeters) per year due to tidal friction. So there will come a time, about 600 million years from now, when the Moon is far enough away that the lunar disk will be too small to ever completely cover the Sun. Then, at best only annular eclipses, a ring of fire surrounding the silhouetted disk of the too small Moon, will be seen from the surface of our fair planet. Of course the Moon was slightly closer and loomed a little larger 100 million years ago. So during the age of the dinosaurs there were more frequent total eclipses of the Sun. In front of the Tate Geological Museum at Casper College in Wyoming, this dinosaur statue posed with a modern total eclipse, though. An automated camera was placed under him to shoot his portrait during the Great American Eclipse of August 21.

 

From: https://apod.nasa.gov/apod/ap171007.html

Astronomy Picture of the Day – Global Aurora at Mars

See Explanation.  Clicking on the picture will download
 the highest resolution version available.Global Aurora at Mars 
Image Credit: MAVENLASP, University of ColoradoNASAExplanation: A strong solar event last month triggered intense global aurora at Mars. Before (left) and during (right) the solar storm, these projections show the sudden increase in ultraviolet emission from martian aurora, more than 25 times brighter than auroral emission previously detected by the orbiting MAVEN spacecraft. With a sunlit crescent toward the right, data from MAVEN’s ultraviolet imaging spectrograph is projected in purple hues on the right side of Mars globes simulated to match the observation dates and times. On Mars, solar storms can result in planet-wide aurora because, unlike Earth, the Red Planet isn’t protected by a strong global magnetic field that can funnel energetic charged particles toward the poles. For all those on the planet’s surface during the solar storm, dangerous radiation levels were double any previously measured by the Curiosity rover. MAVEN is studying whether Mars lost its atmosphere due to its lack of a global magnetic field.

 

Source: https://apod.nasa.gov/apod/ap171006.html

WannaCry a Birthday Gift??

I woke up on the 12th of May, it was my birthday, and I looked on the news feed and saw a burst of articles regarding the WannaCry Ransomware that has swept across the globe.

number20of20symantec20detections20for20wannacry20may201120to2015
In the last few days, a new type of malware called Wannacrypt has done worldwide damage.  It combines the characteristics of ransomware and a worm and has hit a lot of machines around the world from different enterprises or government organizations:

https://www.theregister.co.uk/2017/05/13/wannacrypt_ransomware_worm/

While everyone’s attention related to this attack has been on the vulnerabilities in Microsoft Windows XP, please pay attention to the following:

  • The attack works on all versions of Windows if they haven’t been patched since the March patch release!
  • The malware can only exploit those vulnerabilities it first has to get on the network.  There are reports it is being spread via email phishing or malicious web sites, but these reports remain uncertain.

 

Please take the following actions immediately:

  • Make sure all systems on your network are fully patched, particularly servers.
  • As a precaution, please ask all colleagues at your location to be very careful about opening email attachments and minimise browsing the web while this attack is on-going.

 

The vulnerabilities are fixed by the below security patches from Microsoft which was released in Mar of 2017, please ensure you have patched your systems:

https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

Details of the malware can be found below.  The worm scans port TCP/445 which is the windows SMB services for file sharing:

https://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in-widespread-attacks-all-over-the-world/

Preliminary study shows that our environment is not infected based on all hashes and domain found:

 

URL:

www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com

MD5 hash:

4fef5e34143e646dbf9907c4374276f5
5bef35496fcbdbe841c82f4d1ab8b7c2
775a0631fb8229b2aa3d7621427085ad
7bf2b57f2a205768755c07f238fb32cc
7f7ccaa16fb15eb1c7399d422f8363e8
8495400f199ac77853c53b5a3f278f3e
84c82835a5d21bbcf75a61706d8ab549
86721e64ffbd69aa6944b9672bcabb6d
8dd63adb68ef053e044a5a2f46e0d2cd
b0ad5902366f860f85b892867e5b1e87
d6114ba5f10ad67a4131ab72531f02da
db349b97c37d22f5ea1d1841e3c89eb4
e372d07207b4da75b3434584cd9f3450
f529f4556a5126bba499c26d67892240

 

Per Symantec, here is a full list of the filetypes that are targeted and encrypted by WannaCry:

  • .123
  • .3dm
  • .3ds
  • .3g2
  • .3gp
  • .602
  • .7z
  • .ARC
  • .PAQ
  • .accdb
  • .aes
  • .ai
  • .asc
  • .asf
  • .asm
  • .asp
  • .avi
  • .backup
  • .bak
  • .bat
  • .bmp
  • .brd
  • .bz2
  • .cgm
  • .class
  • .cmd
  • .cpp
  • .crt
  • .cs
  • .csr
  • .csv
  • .db
  • .dbf
  • .dch
  • .der
  • .dif
  • .dip
  • .djvu
  • .doc
  • .docb
  • .docm
  • .docx
  • .dot
  • .dotm
  • .dotx
  • .dwg
  • .edb
  • .eml
  • .fla
  • .flv
  • .frm
  • .gif
  • .gpg
  • .gz
  • .hwp
  • .ibd
  • .iso
  • .jar
  • .java
  • .jpeg
  • .jpg
  • .js
  • .jsp
  • .key
  • .lay
  • .lay6
  • .ldf
  • .m3u
  • .m4u
  • .max
  • .mdb
  • .mdf
  • .mid
  • .mkv
  • .mml
  • .mov
  • .mp3
  • .mp4
  • .mpeg
  • .mpg
  • .msg
  • .myd
  • .myi
  • .nef
  • .odb
  • .odg
  • .odp
  • .ods
  • .odt
  • .onetoc2
  • .ost
  • .otg
  • .otp
  • .ots
  • .ott
  • .p12
  • .pas
  • .pdf
  • .pem
  • .pfx
  • .php
  • .pl
  • .png
  • .pot
  • .potm
  • .potx
  • .ppam
  • .pps
  • .ppsm
  • .ppsx
  • .ppt
  • .pptm
  • .pptx
  • .ps1
  • .psd
  • .pst
  • .rar
  • .raw
  • .rb
  • .rtf
  • .sch
  • .sh
  • .sldm
  • .sldx
  • .slk
  • .sln
  • .snt
  • .sql
  • .sqlite3
  • .sqlitedb
  • .stc
  • .std
  • .sti
  • .stw
  • .suo
  • .svg
  • .swf
  • .sxc
  • .sxd
  • .sxi
  • .sxm
  • .sxw
  • .tar
  • .tbk
  • .tgz
  • .tif
  • .tiff
  • .txt
  • .uop
  • .uot
  • .vb
  • .vbs
  • .vcd
  • .vdi
  • .vmdk
  • .vmx
  • .vob
  • .vsd
  • .vsdx
  • .wav
  • .wb2
  • .wk1
  • .wks
  • .wma
  • .wmv
  • .xlc
  • .xlm
  • .xls
  • .xlsb
  • .xlsm
  • .xlsx
  • .xlt
  • .xltm
  • .xltx
  • .xlw
  • .zip

As you can see, the ransomware covers nearly any important file type a user might have on his or her computer. It also installs a text file on the user’s desktop with the following ransom note:

2cry

How to prepare for PWK/OSCP, a noob-friendly guide

Few months ago, I didn’t know what Bash was, only heard of SSH tunneling, no practical knowledge. I also didn’t like paying for the PWK lab time without using it, so I went through a number of resources till I felt ready for starting the course.

Warning: Don’t expect to be spoon-fed if you’re doing OSCP, you’ll need to spend a lot of time researching, neither the admins or the other students will give you answers easily.

1. PWK Syllabus
1.1 *nix and Bash
1.2 Basic tools
1.3 Passive Recon
1.4 Active Recon
1.5 Buffer Overflow
1.6 Using public exploits
1.7 File Transfer
1.8 Privilege Escalation
1.9 Client-Side Attacks
1.10 Web Application Attacks
1.11 Password Attacks
1.12 Port Redirection/Tunneling
1.13 Metasploit Framework
1.14 Antivirus Bypassing
2. Wargames
2.1 Over The Wire: Bandit
2.2 Over The Wire: Natas
2.3 Root-me.org
3. Vulnerable VMs

1. PWK Syllabus:

Simply the most important reference in the list, it shows the course modules in a detailed way. Entire preparation I did was based on it. Can be found here.

1.1 *nix and Bash:

You don’t need to use Kali Linux right away, a good alternative is Ubuntu till you get comfortable with Linux.

1. Bash for Beginners: Best Bash reference IMO.
2. Bandit on Over The Wire: Great start for people who aren’t used to using a terminal, aren’t familiar with Bash or other *nix in general. Each challenge gives you hints on which commands you can use, you need to research them.
3.  Explainshell: Does NOT replace man pages, but breaks down commands easily for new comers.

1.2 Basic tools:

You will use these tools a lot. Make sure you understand what they do and how you can utilize them.

Netcat: Most important tool in the entire course. Understand what it does, what options you have, difference between a reverse shell and a bind shell. Experiment a lot with it.
Ncat: Netcat’s mature brother, supports SSL. Part of Nmap.
Wireshark: Network analysis tool, play with it while browsing the internet, connecting to FTP, read/write PCAP files.
TCPdump: Not all machines have that cute GUI, you could be stuck with a terminal.

1.3 Passive Recon:

Read about the following tools/techniques, experiment as much as possible.

1. Google dorks
2. Whois
3. Netcraft
4. Recon-ng: Make sure you check the Usage guide to know how it works.

1.4 Active Recon:

  • Understand what DNS is, how it works, how to perform forward and reverse lookup, what zone transfers are and how to perform them. Great resource here.
  • Nmap: One of the most used tools during the course (if not the most). I’d recommend to start by reading the man pages, understand different scanning techniques and other capabilities it has (scripts, OS detection, Service detection, …)
  • Services enumeration: SMTP, SNMP, SMB, and a lot others. Don’t just enumerate them, understand what they’re used for and how they work.
  • Great list for enumeration and tools.

1.5 Buffer Overflow:

Most fun part in my opinion. There are countless resources on how to get started, I’d recommend Corelan’s series. You probably need the first part only for PWK.

1.6 Using public exploits:

Occasionally, you’ll need to use a public exploit, maybe even modify the shellcode or other parts. Just go to Exploit-db and pick one of the older more reliable exploits (FTP ones for example). The vulnerable version is usually present with the exploit code.

1.7 File Transfer:

Not every machine has netcat installed, you’ll need to find a way around it to upload exploits or other tools you need. Great post on this is here.

1.8 Privilege Escalation:

A never ending topic, there are a lot of techniques, ranging from having an admin password to kernel exploits. Great way to practice this is by using Vulnhub VMs for practice. Check my OSCP-like VMs list here.

Windows:Elevating privileges by exploiting weak folder permissions
Windows: Privilege Escalation Fundamentals
Windows: Windows-Exploit-Suggester
Windows: Privilege Escalation Commands
Linux: Basic Linux Privilege Escalation
Linux: linuxprivchecker.py
Linux: LinEnum
Practical Windows Privilege Escalation
MySQL Root to System Root with UDF

1.9 Client Side Attacks:

Try out the techniques provided in Metasploit Unleashed or an IE client side exploit.

1.10 Web Application Attacks

Another lengthy subject, understand what XSS is, SQL injection, LFI, RFI, directory traversal, how to use a proxy like Burp Suite. Solve as much as you can from Natas on Over The Wire. It has great examples on Code Injection, Session hijacking and other web vulnerabilities.

Key is research till you feel comfortable.

1.11 Password Attacks:

Understand the basics of password attacks, difference between online and offline attacks. How to use Hydra, JTR, Medusa, what rainbow tables are, the list goes on. Excellent post on this topic here.

1.12 Port redirection/tunneling:

Not all machines are directly accessible, some are dual homed, connected to an internal network. You’ll use such techniques a lot in non-public networks. This post did a great job explaining it.

1.13 Metasploit Framework:

Decided to skip this part, but if you still want to study it, check out Metasploit Unleashed course.

 

1.14 Antivirus Bypassing:

Skipped this part too.

2. Wargames

Use them as a prep for vulnerable machines.

2.1 Over The Wire: Bandit

Great start for people who aren’t familiar with Linux or Bash.

2.2 Over The Wire: Natas

Focused on web application, many challenges aren’t required for OSCP, but it helps for sure.

2.3 Root-me.org

Has great challenges on privilege escalation, SQL injection, Javascript obfuscation, password cracking and analyzing PCAP files

3. Vulnerable Machines

Boot-to-root VMs are excellent for pentesting, you import a VM, run it and start enumerating from your attacking machine. Most of them result in getting root access. Check the post on which machines are the closest to OSCP, there is also the https://lab.pentestit.ru/ .

Blog posts regarding my journey through Pentestit.ru.:

Pentestit Lab v10 – Introduction & Setup
Pentestit Lab v10 – The Mail Token
Pentestit Lab v10 – The Site Token

How to Sniff a Network: Decoding the IP Layer

 

Following from previous post, which can be found at: How to Sniff a Network : Packet Sniffing on Windows and Linux and How to Sniff a Network : Raw Sockets and Sniffing.

Sniffing one packet is not overly useful, so let’s add some functionality to process more packets and decode their contents.

In its current form, our sniffer receives all of the IP headers along with any higher protocols such as TCP, UDP, or ICMP. The information is packed into binary form, and as shown above, is quite difficult to understand. We are now going to work on decoding the IP portion of a packet so that we can pull useful information out such as the protocol type (TCP, UDP, ICMP), and the source and destination IP addresses. This will be the foundation for you to start creating further protocol parsing later on. If we examine what an actual packet looks like on the network, you will have an understanding of how we need to decode the incoming packets. Refer to Figure 3-1 for the makeup of an IP header.

Figure 3-1 Typical IPv4 header structure
Figure 3-1: Typical IPv4 header structure

We will decode the entire IP header (except the Options field) and extract the protocol type, source, and destination IP address. Using the Python ctypes module to create a C-like structure will allow us to have a friendly format for handling the IP header and its member fields. First, let’s take a look at the C definition of what an IP header looks like.

struct ip {
u_char ip_hl:4;
u_char ip_v:4;
u_char ip_tos;
u_short ip_len;
u_short ip_id;
u_short ip_off;
u_char ip_ttl;
u_char ip_p;
u_short ip_sum;
u_long ip_src;
u_long ip_dst;
}

You now have an idea of how to map the C data types to the IP header values. Using C code as a reference when translating to Python objects can be useful because it makes it seamless to convert them to pure Python. Of note, the ip_hl and ip_v fields have a bit notation added to them (the :4 part). This indicates that these are bit fields, and they are 4 bits wide. We will use a pure Python solution to make sure these fields map correctly so we can avoid having to do any bit manipulation. Let’s implement our IP decoding routine into sniffer_ip_header_decode.py as shown below.

import socket


import os
import struct
from ctypes import *

# host to listen on
host = "192.168.0.187"


# our IP header
u class IP(Structure):
_fields_ = [
("ihl", c_ubyte, 4),
("version", c_ubyte, 4),
("tos", c_ubyte),
("len", c_ushort),
("id", c_ushort),
("offset", c_ushort),
("ttl", c_ubyte),
("protocol_num", c_ubyte),
("sum", c_ushort),
("src", c_ulong),
("dst", c_ulong)
]


def __new__(self, socket_buffer=None):
return self.from_buffer_copy(socket_buffer)


def __init__(self, socket_buffer=None):


# map protocol constants to their names


self.protocol_map = {1:"ICMP", 6:"TCP", 17:"UDP"}


v # human readable IP addresses


self.src_address = socket.inet_ntoa(struct.pack("<L",self.src))
self.dst_address = socket.inet_ntoa(struct.pack("<L",self.dst))


# human readable protocol
try:
self.protocol = self.protocol_map[self.protocol_num]
except:
self.protocol = str(self.protocol_num)


# this should look familiar from the previous example
if os.name == "nt":
socket_protocol = socket.IPPROTO_IP
else:
socket_protocol = socket.IPPROTO_ICMP


sniffer = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket_protocol)


sniffer.bind((host, 0))
sniffer.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)


if os.name == "nt":


sniffer.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON)

try:


while True:


# read in a packet
w raw_buffer = sniffer.recvfrom(65565)[0]


# create an IP header from the first 20 bytes of the buffer
x ip_header = IP(raw_buffer[0:20])


# print out the protocol that was detected and the hosts
y print "Protocol: %s %s -> %s" % (ip_header.protocol, ip_header.src_¬
address, ip_header.dst_address)


# handle CTRL-C
except KeyboardInterrupt:

# if we're using Windows, turn off promiscuous mode
if os.name == "nt":
sniffer.ioctl(socket.SIO_RCVALL, socket.RCVALL_OFF)

The first step is defining a Python ctypes structure u that will map the first 20 bytes of the received buffer into a friendly IP header. As you can see, all of the fields that we identified and the preceding C structure match up nicely. The __new__ method of the IP class simply takes in a raw buffer (in this case, what we receive on the network) and forms the structure from it. When the __init__ method is called, __new__ is already finished processing the buffer. Inside __init__, we are simply doing some housekeeping to give some human readable output for the protocol in use and the IP addresses v.
With our freshly minted IP structure, we now put in the logic to continually read in packets and parse their information. The first step is to read in the packet w and then pass the first 20 bytes x to initialize our IP structure. Next, we simply print out the information that we have captured y.
Let’s try it out.

Kicking the Tires

Let’s test out our previous code to see what kind of information we are extracting from the raw packets being sent. I definitely recommend that you do this test from your Windows machine, as you will be able to see TCP, UDP, and ICMP, which allows you to do some pretty neat testing (open up a browser, for example). If you are confined to Linux, then perform the previous ping test to see it in action.

Open a terminal and type:

python sniffer_ip_header_decode.py

Now, because Windows is pretty chatty, you’re likely to see output immediately.
I tested this script by opening Internet Explorer and going to www
.google.com, and here is the output from our script:

Protocol: UDP 192.168.0.190 -> 192.168.0.1
Protocol: UDP 192.168.0.1 -> 192.168.0.190
Protocol: UDP 192.168.0.190 -> 192.168.0.187
Protocol: TCP 192.168.0.187 -> 74.125.225.183
Protocol: TCP 192.168.0.187 -> 74.125.225.183
Protocol: TCP 74.125.225.183 -> 192.168.0.187
Protocol: TCP 192.168.0.187 -> 74.125.225.183

Because we aren’t doing any deep inspection on these packets, we can only guess what this stream is indicating. My guess is that the first couple of UDP packets are the DNS queries to determine where google.com lives, and the subsequent TCP sessions are my machine actually connecting and downloading content from their web server. To perform the same test on Linux, we can ping google.com, and the results will look something like this:

Protocol: ICMP 74.125.226.78 -> 192.168.0.190
Protocol: ICMP 74.125.226.78 -> 192.168.0.190
Protocol: ICMP 74.125.226.78 -> 192.168.0.190

You can already see the limitation: we are only seeing the response and only for the ICMP protocol. But because we are purposefully building a host discovery scanner, this is completely acceptable. We will now apply the same techniques we used to decode the IP header to decode the ICMP messages. Stay tuned for the next post.

How to Sniff a Network: Packet Sniffing on Windows and Linux

Network sniffers allow you to see packets entering and exiting a target machine. As a result, they have many practical uses before and after exploitation. In some cases, you’ll be able to use Wireshark (https://wireshark.org/) to monitor traffic or use a Pythonic solution like Scapy (which we’ll explore in the later posts). Nevertheless, you can read more: How to Sniff a Network : Raw Sockets and Sniffing.

 

Accessing raw sockets in Windows is slightly different than on its Linux brethren, but we want to have the flexibility to deploy the same sniffer to multiple platforms. We will create our socket object and then determine which platform we are running on. Windows requires us to set some additional flags through a socket input/output control (IOCTL),1 which enables promiscuous mode on the network interface. In our first example, we simply set up our raw socket sniffer, read in a single packet, and then quit.

import socket
import os
# host to listen on
host = "192.168.0.196"

# create a raw socket and bind it to the public interface
if os.name == "nt":
u socket_protocol = socket.IPPROTO_IP
else:
socket_protocol = socket.IPPROTO_ICMP
sniffer = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket_protocol)
sniffer.bind((host, 0))

# we want the IP headers included in the capture
v sniffer.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1)

# if we're using Windows, we need to send an IOCTL
# to set up promiscuous mode
w if os.name == "nt":
sniffer.ioctl(socket.SIO_RCVALL, socket.RCVALL_ON)

# read in a single packet
x print sniffer.recvfrom(65565)

# if we're using Windows, turn off promiscuous mode
y if os.name == "nt":
sniffer.ioctl(socket.SIO_RCVALL, socket.RCVALL_OFF)

We start by constructing our socket object with the parameters necessary for sniffing packets on our network interface u. The difference between Windows and Linux is that Windows will allow us to sniff all incoming packets regardless of protocol, whereas Linux forces us to specify that we are sniffing ICMP. Note that we are using promiscuous mode, which requires administrative privileges on Windows or root on Linux. Promiscuous mode allows us to sniff all packets that the network card sees, even those not destined for your specific host. Next we set a socket option that includes the IP headers in our captured packets. The next step w is to determine if we are using Windows, and if so, we perform the additional step of sending an IOCTL to the network card driver to enable promiscuous mode. If you’re running Windows in a virtual machine, you will likely get a notification that the guest operating system is enabling promiscuous mode; you, of course, will allow it. Now we are ready to actually perform some sniffing, and in this case we are simply printing out the entire raw packet x with no packet decoding. This is just to test to make sure we have the core of our sniffing code working. After a single packet is sniffed, we again test for Windows, and disable promiscuous mode y before exiting the script.

Kicking the Tires

Open up a fresh terminal or cmd.exe shell under Windows and run the
following:

python sniffer.py

In another terminal or shell window, you can simply pick a host to ping.
Here, we’ll ping nostarch.com:

ping nostarch.com

In your first window where you executed your sniffer, you should see
some garbled output that closely resembles the following:

('E\x00\x00:\x0f\x98\x00\x00\x80\x11\xa9\x0e\xc0\xa8\x00\xbb\xc0\xa8\x0
0\x01\x04\x01\x005\x00&\xd6d\n\xde\x01\x00\x00\x01\x00\x00\x00\x00\x00\
x00\x08nostarch\x03com\x00\x00\x01\x00\x01', ('192.168.0.187', 0))

You can see that we have captured the initial ICMP ping request destined for nostarch.com (based on the appearance of the string nostarch.com).
If you are running this example on Linux, then you would receive the response from nostarch.com. Sniffing one packet is not overly useful, so let’s add some functionality to process more packets and decode their contents in the following post.

 

How to Sniff a Network : Raw Sockets and Sniffing

Network sniffers allow you to see packets entering and exiting a target machine. As a result, they have many practical uses before and after exploitation. In some cases, you’ll be able to use Wireshark (https://wireshark.org/) to monitor traffic or use a Pythonic solution like Scapy (which we’ll explore in the later posts). Nevertheless, there’s an advantage to knowing how to throw together a quick sniffer to view and decode network traffic. Writing a tool like this will also give you a deep appreciation for the mature tools that can painlessly take care of the finer points with little effort on your part. You will also likely pick up some new Python techniques and perhaps a better understanding of how the low-level networking bits work.

In the previous chapter, we covered how to send and receive data using TCP and UDP, and arguably this is how you will interact with most network services. But underneath these higher-level protocols are the fundamental building blocks of how network packets are sent and received. You will use raw sockets to access lower-level networking information such as the raw IP and ICMP headers. In our case, we are only interested in the IP layer and higher so we won’t decode any Ethernet information. Of course, if you intend to perform any low-level attacks such as ARP poisoning or you are developing wireless assessment tools, you need to become intimately familiar with Ethernet frames and their use. Let’s begin with a brief walkthrough of how to discover active hosts on a
network segment.

 

Building a UDP Host Discovery Tool

The main goal of our sniffer is to perform UDP-based host discovery on a target network. Attackers want to be able to see all of the potential targets on a network so that they can focus their reconnaissance and exploitation attempts. We’ll use a known behavior of most operating systems when handling closed UDP ports to determine if there is an active host at a particular IP address. When you send a UDP datagram to a closed port on a host, that host typically sends back an ICMP message indicating that the port is unreachable. This ICMP message indicates that there is a host alive because we’d assume that there was no host if we didn’t receive a response to the UDP datagram. It is essential that we pick a UDP port that will not likely be used, and for maximum coverage, we can probe several ports to ensure we aren’t hitting an active UDP service. Why UDP? There’s no overhead in spraying the message across an entire subnet and waiting for the ICMP responses to arrive accordingly. This is quite a simple scanner to build with most of the work going into decoding and analyzing the various network protocol headers. We will implement this host scanner for both Windows and Linux to maximize the likelihood of being able to use it inside an enterprise environment. We could also build additional logic into our scanner to kick off full Nmap port scans on any hosts we discover to determine if they have a viable network attack surface. These are exercises left for the reader, and I look forward to hearing some of the creative ways you can expand this core concept.
Let’s get started.

 

Network sniffing

Additional Resources for Week 3 RITx: CYBER501x Cybersecurity Fundamentals

Kerckhoff’s Principle

Encryption

This video explains how the RSA public key and private key are created to be fully dependent on each other. The first part of the video explains the concepts with paint and colors. The second part contains heavy duty math, which may not be as easily understood:

Heartbleed

These links detail the Heartbleed bug from 2014. This vulnerability shows that even though data is protected both in transit and at rest with encryption, data that is being processed is not protected. The encrypted data needs to be decrypted before it’s processed, and therefore is vulnerable at this stage.

 

Week 3 Additional Resources

Additional Resources for Week 2 RITx: CYBER501x Cybersecurity Fundamentals

Authentication

Exploits

Non-Human Threats

The Verizon Data Breach Investigations Report

Each year, Verizon publishes its Verizon Data Breach Investigations Report (DBIR), which lists and examines thousands of incidents from around the world. Verizon uses that data to create the Data Breach Digest, detailed case studies of cyber crimes that illustrate many of the common or emerging cyber threats.

You will use the Data Breach Digest to delve into a cybercrime case study for an activity in section 2.3.

 

Week 2 Additional Resources