Tzomb1e

So I agree with Eigenvektor, but wanted to add one extra note. While not the most likely scenario depending on the manufacturer, using an SFP port as an extra RJ45 interface can add an additional point of failure (bad module). As long as you get quality hardware, this probably is not going to be an issue. It is always worth keeping in mind just in case you need to troubleshoot any kind of connection issue off of that interface.

It may be worth checking other computers/devices in your network to make sure there is not another infected host that is spreading the trojan/miner. Assuming you did not go to a malicious site (or in the unlikely event that cloudflare redirected you to a malicious website with a poisoned record), depending on the malware it can spread to different hosts on your LAN. It may be that the origin point of infection is on another computer. I supposed there is also the possibility that you could have picked up the trojan prior to you detection and its payload was time based...that is also a bit unlikely for the situation but you never know! Do you know the name of the trojan/miner that was detected? It should be in the logs on Malwarebytes. Malwarebytes labs normally has pretty detailed write ups for what the malware does and how it spreads. Are you sure it was not a false positive?

Very good! I am glad you got it working. I have never tried to use a wireless interface with pfSense, so good to know that it actually works!

So there are quite a few considerations to make with the setup for it to work as intended. The short answer to your question is no, you cannot setup the same interface as the WAN and LAN on a pfSense. The long answer is potentially. You can create rules for either interface of course, so if there is a way to enable hairpinning you could potentially create a WAN rule to allow the filtering and routing of traffic on the same interface. I have never looked for this option in pfSense, so it may make for an interesting exercise down the road. As a precursor, my apologies if I repeat anything you already know or have done. I like to go through the steps to make sure nothing is missed ?. To make it work, you will need to create two bridged network interfaces for the pfSense VM in VirtualBox with separate MAC addresses. This will give your guest psSense its LAN and WAN interfaces so your rules can be applied to one side or the other. You will also need to statically assign different IPs to either interface since your pfSense will be the DHCP server for your LAN and the WAN interface will not be able to pull an IP from another DHCP server. Since the IPs are being set statically, your pfSense box will not have any dynamic routes to know where to forward traffic, meaning you will need to also configure a default static route towards your ISP router across your WAN interface (along with making sure NAT is applied to the outbound traffic so the router sends return connections to the correct interface). This will allow the pfSense to take traffic, know where to forward traffic, and allow the rules to be applied. Then, configure your DHCP server on the pfSense and verify that it is disabled on all other devices in the LAN. One other consideration is how your DNS is setup. If you are using the pfSense, make sure that the LAN interface address is set in your DHCP options and you have either the DNS resolver or forwarder enabled along with upstream servers for recursive lookups. If you want the ISP router to be your DNS, just make sure you have it configured in your DHCP options. Personally, I would let the pfSense handle this so everything is going through one place. TLDR: - Static IPs on LAN and WAN interfaces (bridged in Vbox with different MACs) - Static default route for forwarding traffic to the ISP router - NAT on outbound traffic (should be enabled by default if I am not mistaken) - Rules for filtering traffic - Enable DHCP on the pfSense and disable in all other devices - DNS setup in DHCP options Typically I use pfSense in Vbox to control a sandbox/lab, so one interface on the internal network with my other guest vms and the other bridged. I have never really attempted what we are trying to accomplish here. If I have some time this afternoon, I will try and set everything up like you have and verify I am not missing any steps. Anyone reading this, feel free to correct me if I am mistaken or missing something! It is still early so my brain may not be working at 100 % ? Edit: I forgot to answer your other question about the WAN interface. My bad! In your setup, the WAN and LAN titles are more for direction of traffic rather then what is on either side. Traditionally, yes, the WAN interface is the Internet side with the LAN being the local side. That is still somewhat true here since traffic going out the WAN interface will almost certainly be Internet bound, though its next hop is the ISP router. Small detail, but worth mentioning.

To me it seems that the DC is not registering itself properly with the DNS server, hence why the record has "DC1.lan" instead of "DC1.ecorp.local" when you do a lookup by IP.

I may have missed something in the replies, but do you have your DHCP server assigning the DNS suffix for your domain and do you have it added to your DC? Based on the results below, the FQDN for the DC is still using .local and your DNS is only checking .local.

I will at least add my two cents on this. I may ramble a bit, so forgive me for that or any mistakes. Based on the VirtualBox documentation and a forum conversation, guest OSes see wireless adapters as a wired connection and cannot be seen as a wireless adapter due to how VBox creates the bridge (we have already discovered that, of course). While the guest OS sees the interface as being wired, communications between your guest and your LAN should still work properly. If you absolutely need the interface on your pfSense to show as wireless you must attach a USB wireless adapter and pass it through to the guest (as you have done) and configure the device on the guest. That also means making sure that the adapters you are attempting are supported. See the netgate link below for their supported wireless card documentation. I also have links to Oracle's documentation on bridged networking and freeBSDs official page on configuring wireless below just as a reference. https://docs.oracle.com/cd/E97728_01/E97727/html/network_bridged.html https://www.freebsd.org/doc/handbook/network-wireless.html https://docs.netgate.com/pfsense/en/latest/wireless/supported-wireless-cards.html Personally, I think you should skip trying to make your laptop an AP. USB wireless adapters are not really meant to act as the AP in that relationship and, while they sometimes can work in this function, typically do not give the greatest performance (at least from my experience). With your setup (unless you decide to add another AP), I would probably use the ISP router as your AP and have your DHCP set to use the LAN side interface of the pfSense VM as the default gateway. This would force DHCP clients to send traffic to the pfSense that is meant for outside of your LAN and subject to your firewall rules. You may have to play with the routing on the pfSense as well so it forwards traffic properly. Since it is not inline, anyone could simply set their IP address statically and bypass this. If the ISP router has the capability to do so, you could prevent this with ACLs and NAT on the pfSense. Its a messy solution, of course. Again, just my two cents. Feel free to ignore me. ?

You got it! ?

You need to setup separate networks in Virtual Network Editor that point to either adapter (Edit>Virtual Network Editor...). Once these are setup, you can attach virtual adapters to these on the VM itself. Here is a link to the networking documentation of VMWare Workstation Pro 15. You can get the same documentation for lower versions as well. https://docs.vmware.com/en/VMware-Workstation-Pro/15.0/com.vmware.ws.using.doc/GUID-AC956B17-30BA-45F7-9A39-DCCB96B0A713.html

My question is more out of curiosity...is it normal for people to walk around with music playing out of their closed laptops? I am not sure I have ever seen that...sitting and working on the laptop and letting music play, sure, but never carrying it around like a boombox! I know not everyone can afford bluetooth headsets, high end smart phones, or whatever else...I just thought I would ask! No judgement, just curiosity. Also, go with the SSD...not only will it be mostly unaffected by movement, but it will also speed things up for you.

Investigations of any kind are normally my favorite part of the job, they tend to get passed a little further down the chain anymore however. This is the first one I have been able to take on myself in a while due to copious other projects. And that is more or less all it is: a windows device making noise that got my attention. Our field support team just acquired three greenies right out of school, I have already had my normal "this network is not your playground" talk and specifically asked them about this traffic but I do have my doubts. Fortunately I have some surprise posture assessments in their territories next week that will let me validate their stories, so we will see how things hold up.

The forwarding interface does not have any virtual interfaces. The ingress interface does, though. Unfortunately I cannot share any of the logs. While they do not contain much other than the packet information that I am pulling from my sinkhole, which only has IP, MAC, and information from the DNS query, I am not allowed to share them. Sorry!

I have the IPs, but the only MAC is from the forwarding gateway...which is the forwarding interface of our core router :D. Since it appears to be in a different broadcast domain, I lose the original MAC the second it is forwarded to another LAN segment. The traffic, at least from what the IDS/IPS, firewall, and my sinkhole has caught, has only been DNS queries that are not registering the device name with our DHCP. So the only information the logs give me is the RFC1918 address of the device and the site it is trying to resolve (which has all been normal windows traffic for Microsoft time and NSCI servers). The IP is almost useless since the subnet it is using does not exist in my environment.

I have considered this, but the corporate policies are somewhat lax on what can be used on the network which makes this way too tricky for me to truly consider. Some of the scope options, like lease, I have already worked on. The devices in question were detected by our IPS/IDS and I have been monitoring their traffic across our edge firewall. While I can just block them logically, finding them physically would be best. With my lack of resources, I may just have to settle for the former...but one can dream!

I did not consider a script, for some silly reason. I will work on that. Thanks! I have been trying to convince those that make choices to allow my team to push forward with 802.1x or ISE or really any NAC...but all they see is cost...and, like you said, the administrative overhead would lead to a larger headcount. Thankfully we do use the same vendor for our infrastructure equipment. They have not been properly cared for, however, and centralized management/logging has been hit or miss during setups.