Video - Interpret HTTP and DNS Data to Isolate Threat Actor (30

min)
In this video, I'm going to walk through lab 12.4.1.1, Interpret HTTP and DNS Data to Isolate a Threat Actor.
In the lab, the Kali attacking machine will attack with a SQL injection attack against the web server. The
attacker will also exfiltrate data from the inside LAN to the web server, and then back out to the internet,
where the Kali attacker exists.
The lab involves four virtual machines, all interconnected or networked together. The virtual machines are the
CyberOPS Workstation on our LAN, Metasploitable vulnerable web server in the DMZ, the Kali attacker on
the internet, and the Security Onion distribution of Linux as the firewall router with intrusion detection system
and alerting mechanisms.
Okay, let's get started. I've launched the VirtualBox Manager, and I need to set up my security sandbox. Here
are my four VMs, which I've already imported into VirtualBox. I'll need to set up the CyberOPS Workstation
first. The CyberOPS Workstation. I'll go to Settings. I'll go to Network, and I'll change the network adapter
from Bridged Adapter to Internal Network, and make sure that the name is inside. On my Security Onion
virtual machine, I've changed the amount of base memory, or RAM, on the system... From the default amount
that came with the virtual machine, in my case, I've changed it to 4,608 megabytes, or 4 1/2 gigabytes, of
RAM.
In part one, we set up the environment. So, I'll power on the CyberOPS Workstation. The CyberOPS
Workstation is powered on, so I'll put in the password CyberOPS and log in. Once you're logged in, you'll
need to open up a terminal. I'll put in an LS command And, I can see the directories. I need to go into the
lab.support.files directory, so I'll change to that directory. Inside that directory, I'll do another LS command,
and I'll need to enter the scripts directory. So, I'll change directory to scripts, issue another LS command, and
the script that I need to run is configure as static.sh. This will configure my network interface with a static IP
address, and put me into the security sandbox. I'll run sudu ./ configure as... Static.sh. I'll put in my password,
CyberOPS. And, I now have a static IP address. 192.168.0.11. And the gateway has also been configured. IP
configuration successful.
Now, I won't use the CyberOPS Workstation again till part three in the lab, so I'll close it... And save the
machine state 'cause I'll be using it later. Notice the CyberOPS Workstation is in the saved state. Now, I'll
power on Security Onion, Metaspoloitable, and Kali, in that order. So, I'll start with Security Onion. And, I'll
pause the video and come back when I have all three virtual machines powered on.
I now have three of the four VMs running. You can see here in Oracle VirtualBox, Kali, Metasploitable, and
Security Onion are all running. Here's Metasploitable. Here's Kali. And... Here's Security Onion. At the end of
part one in the lab, what you'll need to do is... Log in to Security Onion with the username analyst, and the
password CyberOPS. And, once logged in, we'll make sure that all of our services have started up
successfully. I'll open up the menu, and open up a terminal. And issue the command sudu service NSM
status. We can see that the SGUIL server, the ossec agent, snort, and all of the other services that Security
Onion runs are okay and running. If you see any fails, then give it some more time, and reissue the command.
In other words, give it more time for all of the services to come up. Okay, this looks good. So, I'll close that.
And, now it's time to go to part two of the lab. In part two, we log in to Kali. Username, root. Password,
CyberOPS. And once you're logged in to Kali, open up Firefox, and we're going to issue a SQL injection
attack against the Metasploitable web server. I'll put in the IP address of Metasploitable in the address bar.
209.165.200.235. And press Enter. And you can see I've reached the Metasploitable2 web server. We're
going to use the Mutillidae tool, which helps to teach about website vulnerabilities, cross-site scripting attacks,
SQL injections, and a bunch more. So, we'll click on Mutillidae. And, Mutillidae is an excellent open-source
tool to learn about web attacks. So, I'll go to the OWASP Top 10. Injection. SQL Injection Extract Data. And
User Info page. This is an example of a vulnerable web application, where the programmer did not use the
recommended security techniques when programming the application, and has not sanitized the user input,

 Cisco and/or its affiliates. All rights reserved. Cisco Confidential Page 1 of 4 www.netacad.com
Video - Interpret HTTP and DNS Data to Isolate Threat Actor

so we'll be able to input reserved commands or keywords in SQL, and craft a query that returns data that is
unexpected by the programmer.
So, what I'll do is... I'll right-click in the input field for name. And I'll inspect the element. And using the
Inspector, I'll change the field from 20 characters, in the input field, to a hundred. And now I can type in a
longer command, and see the command. So, the SQL injection attack that we're going to use is we're going to
close off the username with a single quote. And then we're going to do a union, and select the columns. Now,
the attacker has already done their background reconnaissance, and has figured out that the columns in the
database are CCID, or credit card ID, comma, CC number, for credit card number. CCV. The expiration field.
And then, we need to use a fifth field to map the fields in this user account application. So, the fifth field will be
the null field, and we're gonna extract this data from the... Credit cards table.
So, this is a union where two totally different tables are stacked on top of each other, making one long list of
records. In other words, we'll be able to return the credit card records in the user name and password field
and signature field, in the current database application. So, we're crossing database tables, basically. So,
union select, null. From credit cards. And then, we need to comment out the password field. So, we'll put a
space, double dash, and then another space, and we'll click View Account Details. And you can see
information that's returned should be the username and password of the user and the user signature. Instead,
it's returning all the usernames, and look, all of the credit card numbers, CCVs. The expiration dates, for all of
the credit cards in the database.
If you're interested to learn more about SQL injection attacks, I recommend clicking the Toggle Hints button to
get hints on how to use these pages. Also, Mutillidae has links to YouTube videos where you can learn more.
I've also created a small Notepad file to show the types of commands that you could use in that username
field, and press View Accounts, and it will return different information. For instance, to get an error, a valuable
error message, type in this into the user field, and press View Accounts. To see a successful injection, close
off with a single quote, space, two dashes, and then another space. You have to remember to use the space
at the end. You have to add a space after the two dashes. And then, these are different queries that you can
put in, which will lead you to discovering the databases, the tables, and the column numbers. And, the result
at the end is the final query, which reveals the credit card information. So, on your own time, you can use
these to take a look at the types of results that you would get.
Back to the lab, now that we've successfully produced results and captured the credit card information, the
next part of the lab involves logging into the Security Onion distribution of Linux to see if it was able to
produce alerts and log these attacks. So, what I'll do next is, I'll close Kali, or pause it, by closing it and saving
the machine state. And I'll go into the Security Onion Linux Distribution. In Security Onion... I'll run squeal. Or,
SGUIL. Type in username, analyst. And the password, CyberOPS. Click OK. Select all of your networks to
monitor on your network interfaces, and start SGUIL. The SGUIL window shows me that Security Onion was
able to detect, or create alerts, for the types of attacks that were entered.
So, you can see here that once it got started up, possible SQL injection attempt. iWare Professional SQL
injection. Injection of a select union select. You can see these messages. I'll click Show Packet Data, and
Show Rule, to get more information. You can see the source IP address, the destination IP address, the port
numbers, the packet data, the header information, at layer four and layer three of the OSI model. I'll scroll
down and take a look at one of these alerts. This one says possible SQL injection attempt. And what I'll do is,
I'll right-click either on the count to look at View Correlated Events, or, I can go to the alert, and right-click and
view the transcript.
From a network security defensive perspective, I have this alert, and I need to find out what was happening in
this SQL injection attempt. If I press Search... And put in username... And click Find. And we'll say Find again.
You can see here, username. And then there it is, that's not a username, that's the credit card information.
And you can see there's the signature right here. And, there's another credit card. That's the CCV. This is the
expiration date. And there is the credit card number. So, I can see this information.
So.. SGUIL was able to alert us to this SQL injection attempt, and in the transcript of the alert, I can detect
what exactly was going on. I can also right-click on the alert ID, and open the event in Wireshark, to examine
it in detail. I can click on any of these packets. And click Follow TCP stream. And it's similar to the transcript
window. If I click Find Text, and type in username, I should find similar information. Username was where the
union select was executed. I'll click Find again, and you'll see that there's the information, PHP username.

 Cisco and/or its affiliates. All rights reserved. Cisco Confidential Page 2 of 4 www.netacad.com
Video - Interpret HTTP and DNS Data to Isolate Threat Actor

And, I'm looking for the credit card data. And, there it is. Username. The credit card data. The CCV. And the
expiration dates. If I want to, I can also save this packet capture. Click Save As, and save it as PCAP file for
logging and analyzing later. Not only can I view the alerts in SGUIL and Wireshark, but I can also look at it in
ELSA.
So, I'll go down here. I'll scroll down and double-click ELSA. I've opened ELSA. I'll click Advanced. I have to
accept the security certificate. So, I'll proceed to local host. I'll authenticate with analyst. And CyberOPS. And
under HTTP... Top Potential SQL Injection, I'll click here. And, I can examine the SQL injection attack. You
can see that it's registered it in ELSA at this IP address. 209.165.200.235 I can click that address... And
examine the alert. Scroll down to the bottom alert and get more information. Under plugins, I'll click Get
PCAP. Once again, put in my password. And there's the PCAP. As you can see, Security Onion is a very
useful tool for monitoring and detecting different types of attacks crossing the network.
In part three of the lab, you will exfiltrate data from the CyberOPS Workstation on the inside network back out
to the attacker on the Kali virtual machine in the internet. To do this, you'll send the confidential data file to the
Metasploitable web server, which is also running a DNS server, and then from there, back over to the Kali
virtual machine computer. The goal would be to move the confidential document from inside the network back
out to the internet without being noticed by the Security Onion intrusion detection system and alerting
mechanism.
Let's get started. To do this part of the lab, you'll need to run the CyberOPS Workstation, which I've already
restarted. Security Onion, which is already running, and I've started up Metasploitable virtual machine again.
So, we'll start by working from the CyberOPS Workstation. In the first part of part three, we can get away with
just using these three virtual machines. So... I'll open up the CyberOPS Workstation, and the first thing you'll
need to do is to go back up one directory to the lab.support.files directory. In this directory, I'll use an LS
command, and look inside the files, and you'll see there's a file called confidential.txt. This is our confidential
document that we want to sneak out of the network. Let's take a look at it using the more command.
You can see that it's just a text file that says confidential document, do not share. This contains information
about the last security breach. To sneak this file past the Security Onion, what we can do is, is convert it from
a binary file to a hex file using a hex-dump tool, XXD. So, I'll use the command xxd, dash P, condfidential.txt...
And redirect it to a file named confidential.hex. Okay. I'll do an LS command, and there's our file,
confidential.hex. If I cat that file... You'll see, there's our hex-dump. The way you'll move this file out to the
internet is by way of the Metasploitable web server in the DMZ. The Metasploitable web server is actually a
DNS server. We can see that if we cat /etc/resolve.conf. You'll see that the second name server is
209.165.200.235. Let's see if we can use a DNS query, and prepend this hex code to the beginning of our
query, thereby moving the information from this file out to the DNS server.
For line in. Tick, which is right at the tilde character, we'll cat out confidential.hex. And then we need another
tick. Semicolon do. And then use the drill command, which is like a dig command or NS lookup, it'll do a DNS
query. And, at the front of our DNS query, we'll use the variable, $line, which is each line in our hex-dump,
and we'll put that in front of .ns.example.com. Semicolon, done. And this bash one-liner shell script with a
loop will loop through each line in the file confidential.hex, and then send each line in a DNS lookup. And, that
should get the information effectively out to the DNS server, which happens to be the Metasploitable web
server. Then from our Kali attacking machine, we should be able to grab it from the Metasploitable web
server.
Alright, let's see if this works. I'll hit Enter. And, there we go, there's our first query. You can see there is the
hex-dump at the front of ns.example.com. You can see the query time and the message. And, this will take a
second to send all four queries. And, it's done. Now that it's done, I can close the CyberOPS Workstation. My
work is done here, because we've gotten the information out to the DNS server. Now, for the rest of the lab,
we'll use the Kali virtual machine to get the information from Metasploitable over to Kali. So, I'll close this. And
save the machine state.
Back in Kali, the goal is to go into Metasploitable to get the information that we uploaded to its DNS query
logs. Then we can take that information and turn it back into our confidential.txt file. So, I'll open up a terminal.
And, we're assuming that the attacker has already been able to gain access to Metasploitable. In other words,
the attacker can do a remote SSH connection to user @209.165.200.235... Which is the IP address of
Metasploitable, and we'll make a connection. And if this is the first time that you're SSH-ing to Metasploitable,

 Cisco and/or its affiliates. All rights reserved. Cisco Confidential Page 3 of 4 www.netacad.com
Video - Interpret HTTP and DNS Data to Isolate Threat Actor

you'll need to type in yes when prompted to accept the security certificate. So, I'm prompted for the password,
which is also user. And now I have a remote SSH connection into Metasploitable.
Now, let's take a look at the query log file by catting it out. I'll cat /var/lib/bind/query.log. And you can see at
the bottom of the DNS query records, there is the last four lines which shows our hex-dump in front of the
query ns.example.com. So, that's good. Now, the goal is just to get this information put back into a file. We
can do that using EGREP, which is the Extended Global Regular Expressions Print tool. It's a program which
will scan a specified file line by line, and return the lines, or the characters, that match a pattern given a
regular expression. So, it's also similar to GREP. So, extended GREP.
So, EGREP. We'll do an egrep, dash O. And then between brackets we're looking for characters zero dash
nine, zero to nine, and A to F. And so any line that starts with a character 0 to nine or A to F, and then a
wildcard for any number of characters following that, followed by .ns.example.com. That should match these
four lines at the bottom of the query.log file. And, we have to give it the file to look in, which is at
/var/lib/bind/query.log. And we can perform some operations and filter out the line to remove the
.ns.example.com part, and give us only the number part. In other words, we can do that by putting in a cut
command, and using a dash D, which is delimiter of a dot. And then, if we cut this into four pieces, based on
the dots, then the first field, dash F, is what we're interested in. And then we'll pipe that... To uniq. And then
redirect it into a new file named... secret.hex. Instead of confidential.hex, we'll put it a file this time called
secret.hex.
Alright. There we go. Now, if we do an LS, you can see there's the file secret.hex. If we cat it, it should be our
hex-dump, which it is. Alright. Now, all we need to do is move this file from Metasploitable, the DNS server,
over to Kali. So, what I'll do is, I'll exit out of my Metasploitable SSH connection, and use the SCP program, or
an SCP connection, which goes over to port 22 and uses SSH, We'll do it to user@209.165.200.235... Which
is Metasploitable, and we're just gonna use the secure copy protocol to copy the file from Metasploitable. And
we have to put in the path, which is in... /home/user/secret.hex. And we're gonna copy it to our home folder.
Alright, let's see if this works. We'll need to put in our password. And the file's been copied. Excellent.
So, now if I do an LS, there's the file in our Kali virtual machine. Now, we can return it from a hex file, hex-
dump, back to a binary file, by putting it in xxd dash R, dash P, secret.hex. And redirect the output to
secret.txt, which was originally confidential.txt. We'll do that. And then... Cat it out. And there it is. So that was
successful. So that was the end of our successful data exfiltration from VMWare Workstation to the DNS
server using a DNS query and then copied from the DNS server back over to Kali and converted back from
hex to a text file.
So now, what we can do is, is go into Security Onion, and see if Security Onion was able to detect the data
exfiltration. Now, in Security Onion, we'll put on our security analyst hat, and see if it was able to detect the
data exfiltration. I'll start ELSA. Okay. I'll scroll down and click Advanced, and accept the security certificate.
I'll log in. Analyst and CyberOPS. And I should be able to go over here to DNS, and look for DNS requests.
And, we'll go to the bottom of the requests. And you can see here, at the bottom, there are... The four lines
with the information requests with ns.example.com. You can see this one here. I can click on any one of these
and say, hey, that looks unusual.
Look at this DNS request. That doesn't look like a name. This doesn't look like a server name. So, we'll click
on it. And, you can see the suspicious DNS query here. And what I could do is, I could highlight this
information... These numbers, and say hey, that looks like a hex-dump. I'll copy it. And then... Open up a
command prompt... And issue an echo command, dash N. And then.. Paste the character string. Close it off.
And pipe it... To XXD... And reverse it. And you can see, it says confidential document.
So, the hex codes were... Converted back to binary and now I can see the text, and so this is suspicious
activity and you can see how an analyst that's paying attention to the logs and the alerts would be able to
detect this type of activity. And that's it for the lab. I hope you enjoyed seeing both sides of a security
scenario, from the attack, to the analyst, who needs to detect and report on an attack such as this.

 Cisco and/or its affiliates. All rights reserved. Cisco Confidential Page 4 of 4 www.netacad.com