The Four Emerging AI Trends to Watch in 2018

Thanks to the driving momentum of modern tech innovators seeking to carve a new path forward enhanced by adaptive algorithms, the capabilities of Artificial Intelligence have grown exponentially in recent decades. Much of what once seemed implausible in the realm of AI is now a reality, and the still-emerging use cases for this technology continue to astound.

AI developments shift and change like our technology-infused world itself, but recent breakthroughs show huge potential for the not-too-distant future in this burgeoning space. If you’re intrigued by the possibilities, here are four hot AI-related trends to watch closely in 2018.

1. Autonomous vehicles hit the streets

Easily one of the most talked-about innovations in-development, self-driving cars and other autonomous vehicles remain big news. While it may be a few years before fully autonomous rides hit the market, major car manufacturers and tech companies alike are working overtime to make this a reality.

By using simulation to speed up the validation, training, and testing process, real-time technology has been a big boon to the self-driving car industry. From auto giants like Ford to newer tech startups like Zoox and 51VR, Unreal Engine is used heavily by major companies in the automotive and tech industry for running virtual simulation and AI training used in autonomous cars. It’s a lot cheaper (and safer) to train a virtual car in a world created with Unreal Engine.


51VR is one of many innovative companies using Unreal Engine to create photorealistic virtual worlds for training the future of autonomous vehicle AI.


2. Enterprise gets on-board with AI

Artificial Intelligence can be used in a wide range of applications and technologies. As it matures and evolve into greater capabilities, AI is being used by more and more companies in the Enterprise space, and that’s only going to grow in the future.

Automation has already been proven to be a powerful asset to big business, but experimenting with the many other ways AI can be incorporated into business assets is also becoming more popular and widespread. Facebook, for example, is using AI and machine learning to teach its chatbots how to be more human. Machine learning and AI-powered processes can also save tremendous time, making them an alluring asset for data and analytics-heavy business.

In much the same way we’re seeing Enterprise clients get on-board with using Unreal Engine and Unreal Studio for diverse industries like architectural visualization, product design, aerospace, manufacturing, and more, we expect AI to eventually grow and become a more integral part of these industries further down the road.


A growing number of Enterprise clients are using Unreal Engine for everything from architectural design visualization to virtual AI training and simulation.

3. Robotics takes off

On a basic level, robots have been around for a long time now, though AI advancements are making them more adaptable and interactive than ever. Each year, more exciting new robot prototypes emerge, as the latest “droids” in development showcase great potential for the future of robotics as a more integral part of our modern society.

DARPA and Boston Dynamics have built some promising robots for future defense and military applications, with robots capable of doing backflips, navigating unstable terrain, and even recovering when knocked off balance. Amazon already uses small worker robots to sort, route, and store packages at some of its warehouses. Other companies are working to lower the barrier to making robotics more accessible to the masses. NVIDIA, for example, built its Isaac robotics platform on Unreal Engine, which lets developers use high-fidelity simulation environments to test virtual robots that can be transferred to physical robots.

It won’t be long before we begin seeing more robotics integrated into everyday life in fascinating new ways.


NVIDIA’s Isaac robotics platform is built on Unreal Engine and empowers engineers to test and experiment with their creations in the safety of a virtual environment before proceeding to real-world tests.

4. Content creators turn to AI

By its very nature, the act of creating unique content feels intrinsically human, yet artificial intelligence is proving itself very capable when it comes to quasi-artistic expression or creating diverse forms of content. Artistic-minded robots are surprisingly common in the computing world, with models designed with complex AI algorithms that let them make decisions and express themselves through different styles of painting and drawing.

Beyond the realm of art, content creation is getting a fascinating boost from AI in other areas, too. Marketing and social media is one avenue seeing some interesting use of AI for content generation. Some brands and companies are tapping into the power of machine learning to create custom videos, written copy, images, social media posts, and more — all created through artificial intelligence. AI driven content will likely never replace the nuance of the human touch, but it’s interesting to see the unfolding potential here.


Unreal Engine is used extensively across many creative, tech, and design-driven industries to train AI and power robotics for a broad range of clients.
Try Unreal Engine and Unreal Studio for free and see why it’s so popular among developers in the AI space!

The P Versus NP Problem Is One of Computer Science’s Biggest Unsolved Problems


In the world of theoretical computer science, P vs. NP is something of a mythical unicorn. It’s become notorious, since it remains an unsolved problem. It basically asks this: If it is easy to check that a solution to a problem is correct, is it also easy to solve that problem? Get back to us when you have an answer. (

Why Is This So Hard?

In the P vs. NP problem (, the P stands for polynomial and the NP stands for nondeterministic polynomial time. Did we lose you? Let’s back up. In simpler terms, P stands for problems that are easy for computers to solve, and NP stands for problems that are not easy for computers to solve, but are easy for them to check. Here’s when an example might be helpful: “A farmer wants to take 100 watermelons of different masses to the market. She needs to pack the watermelons into boxes. Each box can only hold 20 kilograms without breaking. The farmer needs to know if 10 boxes will be enough for her to carry all 100 watermelons to market.” (

Behnam Esfahbod / WIkipedia ()

This sample problem is not easy to solve; it requires you to go through every dang possible combination. Checking the final answer, however, is pretty easy. All P problems are also NP problems (if a computer can easily solve it, the computer can also easily check it). The question remains open: Are P problems and NP problems the same type of problem? Or, are there are some problems that are easily verified but not easily solved?

Who Wants To Be A Millionaire—From Math?

You may be wondering who really cares about this sort of thing. Well, if someone could show that P is equal to NP, it would make difficult real-world problems a piece of cake for computers to solve. Oh, and the person who solves this problem would also get $1 million from the Clay Mathematics Institute. The P vs. NP Problem is one of six unsolved Millennium Problems that hold a million-dollar prize for whoever cracks it.

Want to dive even further into the world's toughest math problems? Check out "The Millennium Problems: The Seven Greatest Unsolved Mathematical Puzzles Of Our Time" by Keith J. Devlin. We handpick reading recommendations we think you may like. If you choose to make a purchase, Curiosity will get a share of the sale.

Watch And Learn:
Why is P vs NP Important?

In this video,He explain perhaps the most famous problem in all of Computer Science. Does P = NP? He define the terms and give examples of each. We also programmatically go through the traveling salesman problem. He experiment with a little bit of mixed reality in this video as well.

Sources and References:


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.

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:

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:

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

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



MD5 hash:



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:


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


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 .

Blog posts regarding my journey through

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

Shadow Brokers Release Attack Tool Archives

On April 9 and April 14, 2017, the Shadow Brokers threat group released archives of attack tools and other information that it claims originated from the National Security Agency (NSA). The contents included exploits against Windows, Solaris, and other software from as early as 2008, as well as information about a campaign targeting EastNets, a SWIFT (Society for Worldwide Interbank Financial Telecommunication) Service Bureau.

Despite some reports that the archives contain exploits for unpatched Windows vulnerabilities, SecureWorks(R) Counter Threat Unit(TM) (CTU) researchers determined that there are no functional exploits against fully patched, supported Microsoft software. Several of the vulnerabilities were addressed in Microsoft Security Bulletin MS17-10, which was released as part of March’s patch cycle. Three other exploits target Windows XP, Vista, Server 2003, Server 2008, and IIS 6.x, but Microsoft does not plan to provide patches for these exploits as the products are no longer supported.

Two attack tools target unpatched vulnerabilities in current Solaris versions:

– EBBISLAND is a remote buffer overflow exploit against XDR code that targets any running RPC service.
– EXTREMEPAAR is a local privilege escalation exploit.

Another buffer overflow exploit named VIOLENTSPIRIT targets the ttsession daemon in Solaris 2.6-2.9. The archives also included exploits targeting less-common software such as Lotus Domino versions 6 and 7, Lotus cc:mail, RedFlag Webmail 4, Avaya Media Server, and phpBB.

According to the Shadow Brokers’ April 14 release, the PLATINUM COLONY threat group (also known as Equation Group) gained access to the EastNets network, monitored SWIFT transactions from a select number of targeted financial services institutions between March 2013 and at least October 2013, and had persistent and wide-ranging access to the EastNets network. CTU(TM) researchers assess with high confidence that PLATINUM COLONY is operated by a United States intelligence agency. The group has been active since at least 2001 and likely uses its sophisticated toolset for military espionage and national security objectives, rather than for economic espionage activities.

PowerPoint and Excel documents within the leaked files list SWIFT Alliance Access servers run by EastNets, and several of the servers are marked as compromised for data collection. There is no indication that networks and hosts operated by EastNet customers outside the EastNet environment were compromised, but SWIFT transactions in 2013 could have been monitored by an unauthorized party as they traversed EastNets servers. EastNets released a public statement saying, “The reports of an alleged hacker-compromised EastNets Service Bureau (ENSB) network is totally false and unfounded.” However, the documentation provided in the Shadow Brokers leak strongly suggests a compromise.


Recommended actions:

CTU researchers recommend that clients ensure that the MS17-10 security updates have been applied. In addition, clients should upgrade unsupported Windows operating systems and IIS web servers to a supported version and should restrict external access to RPC services on Solaris servers.

SecureWorks actions:

The CTU research team is investigating the feasibility of countermeasures to detect the published exploits.


If you have any questions or concerns, please submit a ticket via the SecureWorks Client Portal.



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 as shown below.

import socket

import os
import struct
from ctypes import *

# host to listen on
host = ""

# 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
self.protocol = self.protocol_map[self.protocol_num]
self.protocol = str(self.protocol_num)

# this should look familiar from the previous example
if == "nt":
socket_protocol = socket.IPPROTO_IP
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 == "nt":

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


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 == "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:


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, and here is the output from our script:

Protocol: UDP ->
Protocol: UDP ->
Protocol: UDP ->
Protocol: TCP ->
Protocol: TCP ->
Protocol: TCP ->
Protocol: TCP ->

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 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, and the results will look something like this:

Protocol: ICMP ->
Protocol: ICMP ->
Protocol: ICMP ->

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 ( 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 = ""

# create a raw socket and bind it to the public interface
if == "nt":
u socket_protocol = socket.IPPROTO_IP
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 == "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 == "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


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


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

x00\x08nostarch\x03com\x00\x00\x01\x00\x01', ('', 0))

You can see that we have captured the initial ICMP ping request destined for (based on the appearance of the string
If you are running this example on Linux, then you would receive the response from 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 ( 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


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:


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