Using pfSense to selectively allow traffic during dynamic malware analysis


Right now your enterprise network with all its users and systems is a live production lab for any malware or attacker that comes along. If you have an EDR you have an advantageous view of the the endpoints. How about installing that same EDR on your malware analysis system so you can review signatures and TTPs from malware in a controlled environment? You'll be surprised the difference it makes in finding new TTPs.

I have always felt it would be nice to be able to allow some traffic out of a dynamic malware analysis lab without letting it all out. As a rule I don't allow malware to talk directly to the Internet without a very good reason to do so. Now with EDR technology available it became crucial to allow the EDR to be able to connect to the mothership while restricting all other traffic to the host only malware network. But once this is setup we can expand things a bit and allow api.ipify.org and other benign traffic.

Here is how I did it. If you have a different way I would love to hear about it.

Prerequisite
Have a working dynamic malware analysis setup with inetsim or fakenet (potentially others) that controls and returns DNS as the IP of the fake system and redirects IP addresses to the fake system as well. There is a test plan at the bottom to verify a fully functioning system. DNS is normal but I have seen setups that did not redirect IP based traffic. If you are setting up your very first analysis rig don't use these instructions, there are better resources.

My existing setup
Virtual box

Host only network for Inetsim and victim VMs. Inetsim is setup to resolve DNS names back to itself and redirect direct IP based addresses to itself as well.

The victim VM is setup normally as an office user with some tools installed but no AV and it does have our EDR installed which points back to the DMX just like a workstation.

Target setup
Add pfSense to the lab to provide positive control of outbound traffic to the WAN (Virtual Box NAT network) while keeping everything else on the host only network.


pfSense setup

Create a new virtualbox host and attach the pfsense iso.

Add two networks
Host only (for the victim machine and inetsim or fakenet)
NAT for Internet access

Make a note of the mac address for the LAN for later setup.

Power up the VM and let it install.

Option 1 Assign Interfaces
Match up the LAN interface with the correct MAC address
Assign the upstream gateway to your inetsim or fakenet address 192.168.56.101
(you can also do this later in the web interface under interfaces)

Option 2 Set interface(s) IP address
I leave a gap in the low range DHCP from Virtual Box host only network so that I can assign static addresses if necessary. In this case I use the next available address up from my Inetsim address (currently the gateway address on the victims)
192.168.56.102/24

Now you will see the URL for pfsense http://192.168.56.102

The rest of the setup will occur in the web interface.

Setup default DNS IP
Since Inetsim is providing my resolution in the hostonly network I set that IP as the default DNS address. I will actually turn off DNS on pfsense so this may not be necessary. Once the install is complete, turn off  Services/ DNS Resolver and turn off  Services / DNS Forwarder.




Make sure to save changes at each step

Default Gateway
If the overall default gateway was not already set we can set it in System / Routing / Gateways
We want the overall gateway to be the inetsim server (LAN) which is handling all the DNS and IP redirecting for traffic spoofing.




Hybrid NAT
Not sure why this needs to be changed but it does.
Go to Firewall / NAT / Outbound and select Hybrid NAT and save the changes to allow rules to be created.
Create a rule for any to WAN




Firewall rules
The original ruleset looks something like this. I am not using IPV6 so that rule will be turned off.





At first I thought to disable the default rule allowing any any for LAN to WAN but that kills all traffic. The way this is working is that the default gateway is the LAN so while traffic is allowed to the WAN there is no gateway for it to get there until we specifically add rules for each destination we want to allow out.


Testing
At this point we need to fire up our inetsim or fakenet and the victim/analysis VMs to make sure things are working as expected. I need to modify the gateway address on the victim to be the pfsense firewall address 192.168.56.102. Once that is done test the different scenarios. Since we haven't added any rules yet NO traffic should be able to leave the host only network nor get a valid DNS from outside the host only network.

DNS resolution
  • Should return the default address from inetsim that is used to spoof traffic.

Ping a domain
  • Should resolve the name to the inetsim IP and ping correctly

Ping an IP address
  • Should ping correctly

Web browser to FQDN / url
  • Should resolve to the default inetsim address and return the fake page

Web browser to IP address
  • Should return the fake page from inetsim



Add a destination for outbound traffic
Do a lookup for the target you want to allow out of the host only network and add that FQDN and address to your inetsim/fakenet static dns entries.

Here is an example
api.ipify.org 54.225.92.64

Add the rule to pfSense
Add a new rule and put in the destination IP or network address, then open Advanced Options in the Extra Options section to select the WAN network gateway.




Save the rule and allow the changes.

Here is the finished rule. Note that the gateway is the WAN. Earlier we set the default gateway for pfSense to the LAN forcing everything into host only. Having this rule above the others changes the gateway for this specific traffic only.





Next do the same thing for the destination network for your EDR. This was the important traffic that we needed out in the first place.


Disable gateway monitoring
There is a constant ping which will fill up our wireshark traces so lets disable it.



Back to testing
Make sure the original tests still work as designed.

Test traffic to allowed destinations
  • Web access to api.ipify.org works as expected
  • EDR traffic is flowing normally

Wrap up
That should be it, now instead of running two VMs for analysis you'll need to run three but the victim can now be rebooted, snap shot or whatever without risking traffic leaving the host only network. If pfSense is off the victim gateway is incorrect so you'll quickly see the problem.

Happy hunting.


Comments

  1. JuliaApril 22, 2021 at 12:29 AM

    hi. i have a question about some material on this post. You said in pfsense setup section like this "In this case I use the next available address up from my Inetsim address (currently the gateway address on the victims)". What do you mean by "currently the gateway address on the victims"? Is it the inetsim server address or this pfsense address? What should be the gateway of the victim?

    ReplyDelete

Post a Comment

Popular posts from this blog

Misleading extensions Xls.exe Doc.exe Pdf.exe

I get something out of twitter almost every day and it is not uncommon to see examples a few times before the realization sinks in that you are looking at a technique that needs a rule. These should fall under the ATT&CK framework as masquerading. I saw a tweet the other day that reminded me of a couple of signatures worth talking about. These misleading double extensions are not new but they never seem to go out of style. With modern EDRs it is an easy win. The malware filename ended in .xls.exe but lets expand that to include other office file types. index=edr ( doc OR docx OR xls OR xlsx OR pdf ) exe ( process_path=*.doc.exe OR process_path=*.docx.exe OR process_path=*.xls.exe OR process_path=*.xlsx.exe OR process_path=*.pdf.exe ) The sig is largely self explanatory, the tokenization allows for keyword search by breaking up the extension, and the process path stuff just anchors it all to the process name since these are pretty generic terms. Another tweet by blackor
Read more

Netconn from suspicious directories

Suspicious directories are an interesting topic and I am always on the lookout for them as a TTP.  The premise may be that directories like temp and downloads are already under review so some other directory should be used. That is fine for a while but once known it is easy to detect. The problem is noticing the unusual directory and adding it to your detection. I have no idea where I got most of these so if you have a post similar to this I will be happy to reference it. Number one is the recycle bin, nothing should run from here, be referenced from here and certainly not netconn. I also do a signature for $recycle.bin in the command line just to catch anything non-netconn related. These are locations to look for processes doing netconn.  Additional filtering is possible looking for activity from the root of these locations if you have a noisy one or it is a legit higher level path like C:\. A search query for only the root would look something like this: index=edr process_pa
Read more

Powershell DNS C2 Notes

I recently took a look at Powershell DNS C2 and found a couple of interesting things. The special case of DNS requests from powershell should be easy enough to identify using an EDR. Using splunk and stats just look for multiple remote port 53 occurrances from powershell. There will be a few but DNS c2 is noisy so a large limit can be used for filtering. Next I took a look at DNSCat https://github.com/lukebaggett/dnscat2-powershell Interestingly powershell does not make the dns request directly but spawns nslookup to do it. Easy enough to make a signature for that. Again, powershell calling nslookup will occur legitimately, but a large filter for occurrences will filter those out. index=edr powershell.exe nslookup.exe parent_path=*\\powershell.exe | stats values(command_line) count by computer_name parent_process_guid | where count>10 Next I went back to some old Oilrig samples which used DNS C2. Nothing new here, just multiple DNS requests directly from powershell. B
Read more