Lab with Kali, CentOS, Windows, Security Onion

JIB

New Member
Joined
May 10, 2019
Messages
14
Reaction score
0
Credits
0
Hello,

I am working with a penetration testing lab environment that uses Kali Linux 2018 VM (as an attacker), CentOS 7 (as a target), Windows Server 2016 (as a target), and Security Onion 2019 (as the Intrusion Detection system). All VMs are in VirtualBox and are on the same local network (I've attached a screenshot of the network to this message).

I am looking to test out some footprinting commands like "whois", "nslookup", and "traceroute". For example, I am using Kali to issue a command like "nslookup www.google.com" and "traceroute www.google.com". My goal is to receive alerts in Security Onion tools (like Sguil, Squert, Kibana) to detect those footprinting commands from Kali. I am not sure why I am unable to do that. I believe it is because Security Onion cannot see the commands being issued because they are gathering information from websites.

In VirtualBox, I am using a NAT adapter for both Kali and Security Onion. I am able to successfully perform the attacks in Kali but cannot detect them in Security Onion (attacks like nslookup and traceroute, just to name a couple of them).

I would appreciate any suggestions/help with this problem. I am stuck as to how to solve it.

Thank you in advance!

Jacob
 

Attachments

  • Experiment topology.JPG
    Experiment topology.JPG
    29 KB · Views: 1,297


Hi @JIB, and welcome. Kali is way over my head so I won't be any help... sorry. I deleted your duplicate thread, however, as it is bad practice to try to carry on two conversations on the same topic. This forum is more appropriate to your problem. Good luck!

Cheers
 
Dear @JIB I am very much far from hacking but as far as I know, NAT virtual machine does not have its own IP address on the external network. A virtual machine gets an address on this private network from the virtual DHCP server. The virtual machine and the host system share a single network identity that is not visible on the external network, instead of Bridged networking connects a virtual machine to a network by using the network adapter on the host system.

So from the above understand that using NAT connection is not making your virtual machine accessible from a network, it was better if you use a bridge connection.

I don't know, I hope this to be helpful.
 
I'm trying to wrap my head around how you have things set up..

You have kali set up as the attacker..
centos and windows as targets..
Security onion as a 4th system on the network as a detection system..

I've never used security onion before..

So - where's kibana? Do you have an elk stack set up somewhere as well? Are logs from centos/windows getting fed into it? Security onion has some kind of monitors set up in centos/windows?

A whois command from kali won't query any of the machines on your network.. it'll head out to the internet. Same with 'nslookup' unless one of your machines (centos?) is the dns server for the kali machine.

Edit: Looking at security onion now.. i see it comes set up with an elk stack, etc.. looks pretty interesting. I'll set it up this weekend :)
 
Dear @JIB I am very much far from hacking but as far as I know, NAT virtual machine does not have its own IP address on the external network. A virtual machine gets an address on this private network from the virtual DHCP server. The virtual machine and the host system share a single network identity that is not visible on the external network, instead of Bridged networking connects a virtual machine to a network by using the network adapter on the host system.

So from the above understand that using NAT connection is not making your virtual machine accessible from a network, it was better if you use a bridge connection.

I don't know, I hope this to be helpful.

Hi CptCharis, Thank you for this suggestion. I will look into it. Will using bridged networking in VirtualBox work if I am using a wireless internet connection on my host computer?

Thank you again for your time.
 
I'm trying to wrap my head around how you have things set up..

You have kali set up as the attacker..
centos and windows as targets..
Security onion as a 4th system on the network as a detection system..

I've never used security onion before..

So - where's kibana? Do you have an elk stack set up somewhere as well? Are logs from centos/windows getting fed into it? Security onion has some kind of monitors set up in centos/windows?

A whois command from kali won't query any of the machines on your network.. it'll head out to the internet. Same with 'nslookup' unless one of your machines (centos?) is the dns server for the kali machine.

Edit: Looking at security onion now.. i see it comes set up with an elk stack, etc.. looks pretty interesting. I'll set it up this weekend :)

Hi Rob, Thank you. I ran whois and nslookup in Kali and those attacks work. The problem I'm having is detecting them in Security Onion. I installed ELK on CentOS 7 and for another lab (ARP poisoning), I passed the logs from CentOS 7 to Security Onion. I am unsure how I would use an IDS (i.e. Security Onion) to detect a footprinting attack against a website (like nslookup www.google.com for example).

Thank you again for your time.
 
Hello,

I am having trouble performing a man-in-the-middle attack with Kali (as the attacker) and Windows Server 2016 (as the target). Both are VMs in VirtualBox and they are on the same local network (172.16.2.0/24). The instructions of the lab I am following specifies to open three separate terminal windows in Kali: The first window: driftnet -i eth0, the second window: webspy -i eth0 172.16.2.20, and the third window: urlsnarf -i eth0. While those three windows are running, I open an internet browser (like Internet Explorer) on the Windows Server 2016 VM, and browse a couple of websites. I am supposed to see output in the three Kali terminal windows, but am not seeing anything. When I have tried these steps, I am able to connect to the internet on the Windows VM and open a site like www.google.com.

Does anyone have any suggestions of something I can try to fix the lab? My goal is to successfully complete the attack so I can work on detecting the Man-in-the-middle attack with an IDS.

Thank you in advance in any help. I would greatly appreciate it.

Jacob
 
Firstly are you routing all the traffic within virtual box through your Security Onion? From what I have read Security has no way of detecting traffic from Kali to the internet because Kali is directly connecting to it through the virtual box NIC to the physical NIC to the internet. You could also add a virtual firewall to pass all the virtual network traffic through before it leaves the virtual environment.

Secondly I would re-attempt your arp poisoning and make sure your Kali takes the place of your router in your virtual environment. The whole point of the poisoning is to make all the devices believe Kali is the network device and the feeding the actual network device the packets you want it to see and how you want it to see them. And then returning the packets you want back to the original requester and in a format you want it in.
 
  • Like
Reactions: Rob
Hi Drizzit89, Thank you very much for your message. I appreciate it and sorry for this late reply.

I am now using a CentOS 7 router in VirtualBox to send traffic from the local network (containing Kali) to Security Onion (which will be on its own network). If I set up a virtual firewall (as you suggested), would it pass alerts (Kali commands sent to the internet like traceroute...) to Security Onion? And can rules be set up on Security Onion (Snort rules) that would produce alerts (i.e. a rule that detects traceroute)?

Also, I used a tool called "arpwatch" to detect ARP poisoning attacks in Security Onion. I ended up having to pass those Arpwatch alerts from a Centos 7 Victim VM to Security Onion (using so-allow). Is there a similar tool that would be able to detect a Man-in-the-middle attack?

Thank you again for your time,

Jacob
 
You can set this up one of two ways. Personally I would not create tracert or ping and a security rule due to a large amount of noise that is generated by ping and the other tools built off of it (tracert). Tracert is just an automated set of pings with the allowed number of hops increased by one until it reaches the destination or the maximum number of hops (32 default). I would personally set up a rule to fire on a kind of scan, attack or service being used in a suspicious manner, such as telnet/ssh from your kali vlan to your protected vlan or a scan of ports in a short period of time (top 10000 ports in less than 5 minutes). I will write up the rest as tracert but should be able to be used for any sort of scan or service.

First option: You can set up your router to generate logs for specific types of traffic it sees and have Security Onion parse those logs with rules to hit on "suspicious activity". In this case tracert. So you will want the router to make an entry for every ping packet it comes across and forward it to Security Onion. Then you want to create a rule in Security Onion to parse the logs from the router looking for a number of ping requests from the same IP in a short period of time.

Second option: You can setup a firewall with network rules to allow or deny certain types of network traffic, you can get very granular depending on the firewall used. I would setup the firewall to log allows and denies and send them to Security Onion. Then you set up Security Onion with rules like in the first option.

As far as Man-in-the-Middle attacks go they are one of the hardest attacks to detect reliably due to the nature of the attack. Detection is usually done by software on the client side and is usually detected by a bad or certificate mismatch. Credential/session/token replays are in the same boat because there is only so much distrust that can be applied before normal services and resources are negatively impacted. This is why these two attacks are fun, easy to implement, they are hard to detect/protect against by security and are usually OS agnostic.

I would personally start with rules looking for things calling out of my protected vlan on ports they shouldn't be and then compromise my target box with shells or malware to talk back to kali.
 
  • Like
Reactions: Rob
Hi Drizzit89,

Thank you again for your suggestions. Is there a way to detect a MITM attack (conducted with VMware VMs) with Snort?

Also, can Snort be used for detecting IP spoofing? The professor that I'm doing this project for has a preference for incorporating Snort into the labs that we are working on (for detection).

Jacob
 
So JIB,
I am going to answer your questions with questions and comments because it depends on the network and resources available.
What does a successful MITM attack look like?
The user does not see obvious signs of an insecure connection: the browser has a lock by the URL.
What are some of the tell tale signs that modern browsers look for in such attacks?
Browsers will look for self signed certs or certs with unusual expiration patters (too long, already expired).
How do the attackers try to limit the obvious signs of a MITM?
Buying cheap legitimate certs that don't match the actual cert of the hosting server but may be close.
My best suggestion is for the MITM is to determine how you want to reliably detect it and create your snort rule to look for it.
Snort should be able to detect IP spoofing. I would perform an IP spoof against a device using wireshark and review the packets and compare them to a similar normal connection captured by wireshark. Look for differences in packet headers and packet text. I would also stick with simple well known protocols like ping and ftp.
 
  • Like
Reactions: Rob
Hi Drizzit89,

Thank you for your help and for your detailed answer. I appreciate it.

I will have to discuss the MITM attack with my professor to get a better idea of the method he wants to use to detect MITM. I'll keep your suggestions in mind.

I created a Snort rule for IP spoofing and it now is working. Thank you for your help with that.

I'm sorry for this extra unrelated question but I am stuck on a separate lab. The lab I'm working on focuses on exploiting a vulnerability exclusive to Mozilla Firefox (version 3.5.17). The goal of this lab is to come up with a way to detect the attack. But at the moment, I can't successfully complete the attack. The lab environment is VMware workstation 15.

The attacker is Kali (172.16.2.70) and the victim is the Windows Server 2016 VM (172.16.2.20). Firefox version 3.5.17 is present on the Windows VM. In Kali, we are using Metasploit to exploit the vulnerability called "mozilla_nstreerange". After setting options in "msfconsole", a URL is created by Metasploit and is pasted into the Mozilla Firefox browser on the Windows VM.

The problem I'm having is that after pasting the URL link into Windows, the attack freezes/hangs in Kali (after the line that says "sending JS"). I have researched this on Google but can't find anything related to the problem.

Here is what I see in Kali during the attack:

4122


This is what I see in the Windows VM:

4123


These are things that I've tried so far:

  • Turned off the firewall on Windows VM
  • Turned internet on and off for the Windows VM.
  • Changed the "uripath" setting to "/", "evil", and tried calling it "urlpath"
  • Let the attack sit there for hours thinking that it was running slow. But after letting it sit for hours, it is in the same state.
Have you (or anyone else) seen this problem before? I would greatly appreciate any advice or suggestions that you may have.

Also is there a way to detect this attack using Snort? I'm asking because the vulnerability is specific, so I'm not sure if that affects the way it is detected.

Thank you in advance,

Jacob
 
Last edited:
Is Java installed and functioning in Mozzilla? The exploit is dependent on Java.
I would look up the exploit in Armitage and read up on it and verify your Java matches.
 
Hi Drizzit89,

Thank you for your help. I have never used Armitage before but once I opened the exploit I see this:

4152



I downloaded the latest version of Java for Windows Server 2016 VM. But I got the same error. It seems that for the "nstreerange" exploit, Java version 7 must be used. When I go to Oracle's page (through the Internet on the windows VM), I don't see an option to download Java SE 7.

I would appreciate any other suggestions you may have,

Thank you again!

Jacob
 
Here is the link for the Java 7 archived downloads https://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html.
I would agree that Java 7 looks like a requirement. You can sometimes use even older versions as the vulnerability is contained in the main code. The sometimes major rewrites add or remove vulnerabilities like Java 6 to Java 7.
Do you happen to know what CVE you are attempting to exploit? It may be worth while researching the specifics of the exploit and what was implemented to fix it.
 
Hi Drizzit89,

Thank you so much again for your help. The Exploitation lab is now working. When I tried Java 7, the attack got stuck at the same point. But when I downloaded Java 6 on the Windows VM, the attack began to work correctly.

I greatly appreciate your guidance. I wouldn't have ever guessed that Java was the part that was affecting the attack. I don't know what I would have done without your suggestions.
 
Hi Drizzit89,

In order to write a Snort rule for a Man-in-the-middle attack, what protocol can be used for that rule? The reason I'm asking is because the MITM attack for the lab I'm working on, depends on ARP poisoning. ARP is one of the protocols that can not be used in a Snort rule. I've tried TCP and IP so far without any luck. (i.e. alert tcp any any -> $HOME_NET any (msg: "man-in-the-middle attack detected"….)

After reading your last response related to MITM, I feel that Snort would be the most effective tool for detecting the MITM (especially since the Security Onion VM I'm using is able to detect the ARP poisoning that leads into MITM).

I would greatly appreciate any suggestions,

Have a great day and thank you in advance,

Jacob
 
Your best bet is to set a rule in snort to trigger on two or more ARP responses in a short period of time that have different IPs for the same MAC address. You will have to play with the time to make it large enough to detect both responses but short enough not to detect a DHCP IP address change. I may be going about this completely wrong but from my limited knowledge of ARP this should detect the attack.
 

Members online


Top