Talking about networking, how we want the network to
be set up for this virtual machine.
So there are a number of ways in virtual machines that you can set up
networking. It comes out to there being three different types of networking
you can have in VMs. The first is bridged networking,
which is where you're basically sharing your NIC, your network
interface, on your host OS with the virtual machine,
and it basically just kind of creates a separate network for it.
So when you're in bridged mode,
it means that you're on the network that your host OS is on.
There is NAT mode,
which allows your virtual machine to kind of go through
your host OS's network interface,
but it's not requesting a new IP address on the network that you're on.
So all the traffic looks like it's coming from your host OS.
Now with bridged and NAT mode,
you're allowing the malware and your guest 0S to get to the internet,
and you may not want to do that.
In fact,
I recommend at least the first time you run malware, you put
it into this third type of networking, which is called host‑only networking.
And it basically creates a private network within your host OS and your
guest OS so that your guest OS can't get to anything else.
In fact,
probably the only thing that it can get to is either other virtual
machines that are on your host‑only networking network or your
host OS. And with that host network, it's still a network,
right?
It's not like you don't have a NIC attached at all.
It's going to get an IP address. It's still going to have a gateway.
Yes. Awesome.
So it's still going to work.
The guest OS is going to look like it's on a network because it is on a
virtual network. It's just not able to get to the network that your
host OS is connected to. So if you wanted to simulate maybe another VM
or some sort of enterprise asset, you can put it on the same host network,
and those two VMs would be able to see each other.
Yes, and, again, that goes back to why we want to use virtual machines
because we can throw up a second or third or fourth virtual machine and
put it on the same host‑only network and allow the malware to try to
connect to it. Think of it like this. A lot of malware may try to get to
things like domain controllers, Active Directory servers, file servers,
things like that.
We could install a second or third virtual machine under our VM software,
put it on the host‑only network, and allow the malware to try to connect
to it. We could essentially simulate an entire enterprise under our own
VMs if we needed to. Absolutely.
You could have share drives running and full domain. You can join the domain.
Yeah, exactly.
And we're doing all this, we're controlling it.
And we're not allowing the malware to escape out to the internet,
to the network that we're connected to, to our
organization's network, and so on.
So as we get more advanced in it, we're not just simulating the
hardware. We're not just simulating a real OS.
We're also going to simulate a real network infrastructure and
potentially real resources and services that would normally be on a
network. Right. Now the one thing that I'll say, too, is when you're
in host‑only networking mode,
your guest OS is by default going to be able to connect to your host OS.
And, again,
you may not want that to happen. If you're guest OS is running
malware that has a zero‑day exploit in it that could
potentially affect your host OS, you may not want it to be able
to communicate over the network.
So there are ways that we can turn off that connection in the host‑only
networking mode so that our guest OS does not connect to our host OS or
it doesn't even have the ability to do so.
I got it.
And so as I understand it, even on a host OS,
there's a gateway,
and that gateway is a virtual interface on your device that is shared
now. There's a default route to that gateway from your host OS to get
to the guest. So that's something that we should be concerned about,
potentially put some firewall rules on. Potentially put some firewall
rules, or we can actually modify it within a VMware itself and tell
VMware just don't even allow the guest OS to even be able to access the
host OS.
Excellent. Do you want to show me that?
Yeah.
So what we're going to do is we're going to go into VMware, and we're going to
modify the virtual network settings. Right here I have VMware up and running. I
have a Windows 10 virtual machine up and running.
But what we're going to do is we're going to go up to the Edit
menu and go down to Virtual Network Editor.
And what this is going to do is it's going to load up the way that we can go in
and modify any of the virtual network settings within VMware. And what I'm going
to do is I'm going to go down here to Change Settings. I'm going to click
through all this. And once it comes back up,
what it's going to do is it's going to allow us to modify the
settings for the host‑only network. And then you apply that to
whatever virtual NIC is attached to the VM. Yes.
So here the Virtual Network Editor has come back up.
You can see that I have three networks here, the three
networks that we talked about. I have bridged.
I have NAT. And then I have host‑only,
and I want my virtual machine that I'm going to be
running malware be in host‑only mode.
But I don't want it to be able to connect to my host OS.
Each of those seem to have a different subnet as well.
Exactly.
You can go in here, you can modify the VM settings, the IP address settings,
the gateways. All that fun stuff you can modify in here. But I'm going to
select host‑only, and then down here where it says Connect a host virtual
adapter to this network, I'm going to uncheck that.
I see.
Then just click OK, and it saves it.
And now my guest OS cannot talk to my host OS.
I see.
And so if I run any malware in here,
what's going to happen is that malware is not going to be able
to talk to my host was over the network.
Now,
if there are any VM escape exploits within there, it's still could
escape out to the host OS because that goes through a different
interface. It doesn't go through the network. However,
at least now it's not going to be going over the network to get to the host
OS, which you may want and you may not want. You may want to allow your host
OS and your guest OS to talk over the network,
but at least we have the option to turn that off.
Yeah, absolutely.
So if we're in VirtualBox or Hyper‑V, essentially what we're doing is,
there's probably some checkbox for this in those as well, essentially what
we're doing is taking that gateway or that default route for the host
network that the VM's taking out to get to the host, we're taking that and
disconnecting it from the host.
So it still is there for the VM, but it's not routable from the host
OS. So whatever setting you need to do to do that,
that's how you cut it off.
Great. So with this in these network settings,
if we wanted to monitor the network traffic or do
simulations for network traffic, how are we going to do that?
So there are a couple ways that you can do, and at that point,
you kind of need to rely on some tools to help you out.
And there are a number of tools that you can use for this.
One tool from FireEye is called FakeNet.
And what FakeNet does is you run it in your guest OS so you
don't need any other separate systems.
You only need your single virtual machine and you run that.
And what FakeNet does is it will basically intercept all the traffic going out
over the network from your virtual machine and respond to it.
So if you're running malware and your malware makes a DNS request, FakeNet
is going to capture that DNS request and respond to it.
And then if the malware then tries to go to a web server or some other
IP address, FakeNet is going to capture that and respond to it, and
it's going to be logging all of this as it goes through. It logs both
the text of the connections,
saying this program tried to go to this IP address and so on.
And it's also going to log those as PCAP. So you can then go in and use
Wireshark or Suricata or Bro or any other network analysis tool that can
analyze PCAPS to analyze that network traffic. That's great.
So, really,
what you're being able to do is by simulating or putting kind of a
proxy layer in between the network and the malware, you're able to
then capture the indicator as a compromise. Right. So when we're
looking at static analysis,
that's the stuff that's going to pop into memory as we ran the machine
if we dynamically debugged that malware. Right. But, instead now,
instead of having to to understand how to do any of that or unpack it or
hit the correct entry point or anything, we essentially just
double‑click the malware, let it do its thing, and then let FakeNet tell
us where it's going to go.
So we get domains and IPs and that kind of thing that we can use to
then search throughout the rest of our environment.
Yeah,
that's exactly what we're doing here. We're setting up our environment
so we don't have to go in and understand assembly.
We don't have to go in and try to deobfuscate IP addresses or strings or
hostnames or anything like that. We're going to let the malware kind of unpack
itself, undo all of its protections that it might have in place so that we can
monitor how it interacts with the environment.
Yeah, that's awesome.
And I've used TCPView.
Is that what you‑‑‑another thing you mentioned that I think is really important
is we can look at a PCAP and you can kind of come from a network perspective,
and this goes back to monitoring security operations, we kind of look at the
network and then separately we look at the host. But when we're detonating the
malware, a really important part is tying that process to the TCP connection to
the network indicators.
That's a much better behavioral analysis capability
than you would otherwise have. Yeah,
and that's a good point here. With FakeNet, it actually will
tie that process, the process ID, the process name to the
process that made that connection.
There's another way to do kind of this network
simulation where you use a second system.
So what you would do is we had talked about we can set up a second VM and have
it be on the same network. We could do that and set up a, let's say like a
Linux VM and run software like INetSim or PyNetSim,
which are essentially just a bunch of scripts that do the same thing
that FakeNet does, except they run on another system.
And so there's a bit more configuration that's needed on your end.
You need to do things like on your Windows guest, set up the DNS
server to be your Linux box that's running the software, the default
gateway to be the software, and so on.
But it still might work.
You still might need to go down this route because malware
might be looking to see if FakeNet is running,
and if it is,
it might not work, or it might it not execute like you expect it to.
So you have to have that second system somehow.
Now when you have the second system like this, and
you're using INetSim or PyNetSim,
in order to capture the network traffic and fake the malware into
thinking that it's on the internet or network, you lose that ability
to see what process generated that traffic.
I see.
So you're going to need other tools to be able to
correlate that information? Exactly.
It's a really good point.
And then also you talked about having to set up DNS and
potentially DCP or whatever is going to make it look like a real
kind of network environment for enterprise.
But that goes back to comfortability level. If you're not comfortable
using VirtualBox versus VMware, then don't do it.
If you're not comfortable setting up DNS in a way that you
think's going to make sure that you're protecting your host OS
or whatever else you're connected to,
then don't do it. You're making a good point here
in that we're analyzing malware,
but it's still not something that I would recommend for somebody beginning
in computers or IT or security to necessarily do. You do need to understand
how to do these things and why you need to do these things and when you
should do them. We're talking so far about initially having your malware
only connect over the network in host‑only network remote so it can't get
to the internet.
Right. There are times where you do want the malware to
connect to the internet or to another network,
and so you have to put your VM in NATs or bridged mode to allow it to do that.
But you also have to understand the consequences of doing that and why
you should do and, more importantly, how you should do that. You want
to make sure you're not connected to your corporate network when you're
doing it or even any network that's able to be attributed back to you
because looking at the worst‑case scenario, if the attacker sees that
you're analyzing their malware from an IP address that they don't
expect, they could attack back,
they could launch a denial of service attack back at you.
And this stuff has happened, so you really do need to be careful if and when
you do this. I've seen where malware authors will leave notes for reverse
engineers from FireEye and stuff. Absolutely.
I've even had malware that I've been analyzing that I wanted to connect up
to the network where I've had the malware author start chatting with me in
my virtual machine and start asking me questions, and we get into a
conversation. So this stuff does happen.
That's great.
Were they nice at least? They were nice. There were nice.
Well, that's good. I kept trying to get them to give me some
interesting information, who they were, where they were at.
Unfortunately, they didn't fall for that, but it does happen.