You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
not sure if this is the right place to ask but I am kind of out of ideas.
If I place the implant using phantap between a supplicant and the 802.1X-capable switch I can not successfully scan other devices in the network (connected with the switch) using nmap. Even if I skip the host detection there aren't any results. Other tools like ping or wget work flawlessly so I can definitely reach the devices. Interestingly I do get results if I scan unprivileged so I expect that this is related to the way libpcap works?
I also have an instance of silentbridge with the interaction-mode working that works perfectly. The implementation of silentbridge is very similar, but one key difference is that it is using [ip,eb]tables. This brings me to the point that I assume this is due to the firewall settings. Maybe this is related due to the missing MAC SNAT feature that ebtables has?
I tried scanning using nmap <IPv4> and nmap -PE <IPv4>. Adding the (bridge) interface as an option does not help. Temporarily enabling ARP support for the bridge interface does not help either. My tcpdump-PCAPs show that the packets get send and received, but nmap seems to not react.
I've compared silentbridge and phantap using tcpdump on the interfaces (br-phantap / br0 for the implant and eth0 one of the scanned device). On the bridge-interface of both implementations the original (SRC) MAC address was still in use while the SRC IPv4 address was already spoofed for send packets. The recording on the interface of the scanned device shows that the SRC MAC address was replaced to the victim / supplicant MAC. Received packets on the bridge-interface both have the bridge-MAC-address as the DST MAC address. However one difference was that on the bridge-interface received packets on phantap still used the spoofed IPv4 address while on silentbridge this address was already replaced with the IPv4 address of the bridge-interface (169.254.X.Y). Maybe this is the reason why libpcap and therefore nmap has problems interpreting the answer?
If I add the parameters -S <IPv4> in order to spoof the source IP address and add the interface using -e <interface> in nmap then the scan seems to work. However I do not get why this is needed. Besides this also leaks the bridge-interface IP address ...
I've also tried adjusting the nftables-rules - without any luck. E.g. I wasn't able to change the priority of the IP-NAT-rule. Also removing the nftable-rules for interacting with the victim / supplicant haven't helped. I also thought it might be related to a bug in nmap or libpcap, so I tried to downgrade the versions using:
However the problems persisted even with older version of nmap or libpcap.
Is this all due to the fact that nftables are used and they behave differently? Or could there be another reason for this to fail? Has anybody also noticed this behavior and is there a way to fix this?
Thank you!
The text was updated successfully, but these errors were encountered:
Hi @konstantingoretzki
I don't remember what silentbridge does.
Phantap relies on Linux connection tracking + nat to spoof the victim (or gateway) and to get the responses back.
Normally raw socket get the packets before nftables/iptables and inject it after, but as we are using a bridge we might see the packets in the bridge table, to be tested.
Hey there,
not sure if this is the right place to ask but I am kind of out of ideas.
If I place the implant using phantap between a supplicant and the 802.1X-capable switch I can not successfully scan other devices in the network (connected with the switch) using
nmap
. Even if I skip the host detection there aren't any results. Other tools likeping
orwget
work flawlessly so I can definitely reach the devices. Interestingly I do get results if I scan unprivileged so I expect that this is related to the waylibpcap
works?I also have an instance of silentbridge with the interaction-mode working that works perfectly. The implementation of silentbridge is very similar, but one key difference is that it is using [ip,eb]tables. This brings me to the point that I assume this is due to the firewall settings. Maybe this is related due to the missing MAC SNAT feature that
ebtables
has?I tried scanning using
nmap <IPv4>
andnmap -PE <IPv4>
. Adding the (bridge) interface as an option does not help. Temporarily enabling ARP support for the bridge interface does not help either. Mytcpdump
-PCAPs show that the packets get send and received, butnmap
seems to not react.I've compared silentbridge and phantap using
tcpdump
on the interfaces (br-phantap
/br0
for the implant andeth0
one of the scanned device). On the bridge-interface of both implementations the original (SRC) MAC address was still in use while the SRC IPv4 address was already spoofed for send packets. The recording on the interface of the scanned device shows that the SRC MAC address was replaced to the victim / supplicant MAC. Received packets on the bridge-interface both have the bridge-MAC-address as the DST MAC address. However one difference was that on the bridge-interface received packets on phantap still used the spoofed IPv4 address while on silentbridge this address was already replaced with the IPv4 address of the bridge-interface (169.254.X.Y
). Maybe this is the reason whylibpcap
and thereforenmap
has problems interpreting the answer?If I add the parameters
-S <IPv4>
in order to spoof the source IP address and add the interface using-e <interface>
innmap
then the scan seems to work. However I do not get why this is needed. Besides this also leaks the bridge-interface IP address ...I've also tried adjusting the nftables-rules - without any luck. E.g. I wasn't able to change the priority of the IP-NAT-rule. Also removing the nftable-rules for interacting with the victim / supplicant haven't helped. I also thought it might be related to a bug in
nmap
orlibpcap
, so I tried to downgrade the versions using:However the problems persisted even with older version of
nmap
orlibpcap
.Is this all due to the fact that nftables are used and they behave differently? Or could there be another reason for this to fail? Has anybody also noticed this behavior and is there a way to fix this?
Thank you!
The text was updated successfully, but these errors were encountered: