Am I Spying on Myself?

2023-03-18
3 min read

Yes, yes I am.

Back almost a year ago, in Logfile_dump Week 15/22 I said that I tried to set up the combo of RITA/Zeek/MongoDB and Bettercap, like how Strand talks about in the BHIS webcast “No SPAN Port? No Tap? No Problem!” The idea being that Zeek needs packets to be able to zeek them, and then that can forward the logs to RITA in order to do beacon detection, but most people don’t have hardware that can get all those packets so Zeek isn’t going to work.

The workaround that the BHIS crew came up with was to arp cache poison yourself and then that data can be processed by Zeek and go on through the chain. When I initially set it up, it failed pretty hard. I ran into issue after issue with getting things installed, and then when everything was finally up and running I turned on the arp cache poisoning feature in Bettercap and everything just shit the bed and I lost all internet connectivity.

Life happened and I never got back around to fixing it. Ben Heater made a comment at the time that it sounded like I wasn’t forwarding the packets through to the real router, but there wasn’t an obvious setting for that in Bettercap so I just dropped the project all together.

When Active Countermeasures released the AC-Hunter Community Edition though, I knew I needed to start this project up again now that I’m more familiar with what I’m doing. Keep in mind, when I first tried the project before, I was only a few months into Linux and computers so was really just copying and pasting things and hoping it would work.

I took a bit of a different route this time. Instead of having AC-Hunter/Zeek/MongoDB and Bettercap all on the same raspberry pi device, I separated it out a little. Zeek/MongoDB and Bettercap are on the same raspberry pi running Ubuntu Server 22.04 LTS, but AC-Hunter now lives in a Ubuntu Desktop 20.04 LTS VM on my computer for when I want to process the beacons. This probably wasn’t necessary, but it’s a little more convenient for me.

After getting things set up, I ran into the same problem as before though. Gateway-bound traffic just died. Bettercap by default has two different options for arp cache poisoning, spoofing which is supposed to forward the traffic to the real router, and ban which is supposed to drop the traffic. I knew I wasn’t banning the traffic, so Bettercap wasn’t the issue. Googling around, I saw people talk about needing to enable the kernel module for IP forwarding. Well that’s gotta be the solution! I looked around and found this guide from linuxconfig and ran the command to check the IP forwarding status:

# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Crap! My kernel was already set to forward packets. I looked around more and couldn’t find another possibility. What else could it be???

I went back to the linuxconfig article and actually read the damn thing. At the very bottom, with only two paragraphs and a code block, was the solution. iptables. It was set to drop by default all FORWARD packets. (You can check this by running # iptables -L -v -n and looking for Chain FORWARD (policy <look here>).) I changed this to have the default policy of ACCEPT and suddenly like magic, I could reach the beautiful internet again.

I’m officially arp cache poisoning my own house. Now to figure out what all those beacons are…