Usage of SETH using public IP's as host IP

[gurkankkk]

When I try to intercept RDP locally with my KALI LINUX VM having IP 192.168.11.40 & my victim (local PC) 192.168.11.64 I fail to get any SYN packet if I use the public IP of my RDP test server.

My command looks like ./seth.sh eth0 192.168.11.40 192.168.11.40 150.5.5.5
the public ip is not real in this case of course.

The script stays idle at the step [*] Waiting for a SYN packet to the original destination...

If i force RDP connection on my local PC (victim), i see nothing 'moving' in the script window.

Is this because public IP's are not supported as host IP's in the script?

[AdrianVollmer]

Yes, this can't work. Instead of the public IP, you should use the gateway (you can find it with `ip r|grep default`). Note that you use the same IP for victim and attacker (I assume accidentally). Seth does ARP spoofing, and ARP spoofing only works in the same subnet. That's why you need to specify the gateway, so you become MitM between the victim and the gateway from which traffic is routed to the internet.

[gurkankkk]

Yes, this can't work. Instead of the public IP, you should use the gateway (you can find it with ip r|grep default). Note that you use the same IP for victim and attacker (I assume accidentally). Seth does ARP spoofing, and ARP spoofing only works in the same subnet. That's why you need to specify the gateway, so you become MitM between the victim and the gateway from which traffic is routed to the internet.

Thank you very much. All is up and running. I just have a question: why does this not work with rdp connections secured by a public certificate? i still don't understand the difference between them and the funcitonality of this tool.

I have 2 environments: a environment with a public cert and an environment with a self-signed cert. The tool works with the self signed cert by why not with the public cert? why can't it spoof the public one

[AdrianVollmer]

Well, it should work all the same. The difference is that with public certs the user won't get a warning during regular usage. Then when you launch this attack the user suddenly gets a warning. The problem with self signed certs is that you also get this warning during regular usage, so the user won't get suspicious if an actual MitM attack occurs.

…

On Thu, Apr 09, 2020 at 04:38:58AM -0700, gurkankkk wrote: > Yes, this can't work. Instead of the public IP, you should use the gateway (you can find it with `ip r|grep default`). Note that you use the same IP for victim and attacker (I assume accidentally). Seth does ARP spoofing, and ARP spoofing only works in the same subnet. That's why you need to specify the gateway, so you become MitM between the victim and the gateway from which traffic is routed to the internet. Thank you very much. All is up and running. I just have a question: why does this not work with rdp connections secured by a public certificate? i still don't understand the difference between them and the funcitonality of this tool -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #50 (comment)

[gurkankkk]

But I still don't understand why we have the following error for a public certificate protected rdp:

The connection has been terminated because an unexpected server authentication certificate was received from the remote computer.
Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

we don't have this for non public cert protected rdp environments and we're scratching our heads to know why

[gurkankkk]

nevermind, i managed to intercept using SETH_DOWNGRADE=1