Port 60000 attacks, anyone info on this?

ivicask · Tue Sep 18, 2018 11:45 am

After recently one of our server got hacked over RDC and got crpytolocker i noticed theres frequent port 60000 TCP to 3389 and also other random ports attemps.

After bit googling it says that port 60000 is "deepthroat" trojan attack port.

For now i added firewall rule to catch all source port 60000 attempts to blocked address list(port scanners list which i already use) and for now its catching all Russian addresses.

Anyone any info on this, or maybe wanna check if your router also getting this attacks?

/ip firewall filter
add action=add-src-to-address-list address-list="port scanners" address-list-timeout=2w chain=input in-interface=pppoe-out1 log=yes log-prefix=DEEPTHROAT protocol=tcp src-port=60000
add action=add-src-to-address-list address-list="port scanners" address-list-timeout=2w chain=input in-interface=pppoe-out1 log=yes log-prefix=DEEPTHROAT protocol=udp src-port=60000
add action=drop chain=input comment="dropping port scanners" log=yes src-address=!192.168.0.0/16 src-address-list="port scanners"

mkx · Tue Sep 18, 2018 3:29 pm

I don't get it why would anybody want to allow connections to some random port (3389 is as nice random number as any other between 0 and 65536) from internet at large?

Your firewall rule is not complete ... attacker can easily change source port to some other and your rule won't catch anything. I guess the tool used by attackers is really a "script kiddie" class ... if I'd create one, first thing to do would be to randomize source port number.

R1CH · Tue Sep 18, 2018 4:02 pm

3389 is RDP, just a standard probe for vulnerable servers. Your firewall should be dropping this without requiring a dedicated rule.

ivicask · Tue Sep 18, 2018 4:16 pm

I don't get it why would anybody want to allow connections to some random port (3389 is as nice random number as any other between 0 and 65536) from internet at large?

Your firewall rule is not complete ... attacker can easily change source port to some other and your rule won't catch anything. I guess the tool used by attackers is really a "script kiddie" class ... if I'd create one, first thing to do would be to randomize source port number.

Iv put rule to to mark any attempts to dst port 3389 regardless of source port, and only ones that come in one month are from 60000 port(and the other one im using), also its probing other ports other than 3389, and all comes from weird IP adresses from russia as i said..

And when they where hacked there was open connection from 60000>3389(We just got into this company previous tech guys didint change default port)

So tell me what im supposed to do?Just ignore it?I already changed default RDP port and added single white list adress which can acces RDC, but this attempts are still comming in from same adresses/country that hacked them before.

mkx · Tue Sep 18, 2018 4:26 pm

I don't get it why would anybody want to allow connections to some random port (3389 is as nice random number as any other between 0 and 65536) from internet at large?

Your firewall rule is not complete ... attacker can easily change source port to some other and your rule won't catch anything. I guess the tool used by attackers is really a "script kiddie" class ... if I'd create one, first thing to do would be to randomize source port number.
Iv put rule to to mark any attempts to dst port 3389 regardless of source port, and only ones that come in one month are from 60000 port(and the other one im using), also its probing other ports other than 3389, and all comes from weird IP adresses from russia as i said..

And when they where hacked there was open connection from 60000>3389(We just got into this company previous tech guys didint change default port)

So tell me what im supposed to do?Just ignore it?I already changed default RDP port and added single white list adress which can acces RDC, but this attempts are still comming in from same adresses/country that hacked them before.

Even if you properly drop connections from Russia, they will keep trying. And if you have "log=yes" you will have all those tries in your log even though all those tries are not successful (as you have action=drop, the log message is benign ... if someone would successfully connect through, it wouldn't be logged under this firewall filter rule).
I'd just set log=no and (more or less) forget about it. Or, if you have a general rule at the end of list to drop anything not explicitly accepted by previous rules, you can safely remove these FW rules completely and let ultimate rule drop them.
The only benefit of having filter acting on src port 60000 is that it's being used as honey-pot and the third shown rule drops any connection from offending remote address, even to otherwise allowed services (if there are some and if rules shown are at the top of filter rules list).

ivicask · Tue Sep 18, 2018 4:29 pm

I don't get it why would anybody want to allow connections to some random port (3389 is as nice random number as any other between 0 and 65536) from internet at large?

Your firewall rule is not complete ... attacker can easily change source port to some other and your rule won't catch anything. I guess the tool used by attackers is really a "script kiddie" class ... if I'd create one, first thing to do would be to randomize source port number.
Iv put rule to to mark any attempts to dst port 3389 regardless of source port, and only ones that come in one month are from 60000 port(and the other one im using), also its probing other ports other than 3389, and all comes from weird IP adresses from russia as i said..

And when they where hacked there was open connection from 60000>3389(We just got into this company previous tech guys didint change default port)

So tell me what im supposed to do?Just ignore it?I already changed default RDP port and added single white list adress which can acces RDC, but this attempts are still comming in from same adresses/country that hacked them before.
Even if you properly drop connections from Russia, they will keep trying. And if you have "log=yes" you will have all those tries in your log even though all those tries are not successful (as you have action=drop, the log message is benign ... if someone would successfully connect through, it wouldn't be logged under this firewall filter rule).
I'd just set log=no and (more or less) forget about it. Or, if you have a general rule at the end of list to drop anything not explicitly accepted by previous rules, you can safely remove these FW rules completely and let ultimate rule drop them.

I have log for now so i see whats going on, they where hacked over RDP and cryptlocker locked server(strong pass and updated server, av,firewall etc), i dont care about log for now until im sure it wont happen again or they find some other hole, i kinda feel safer to block it, i was just wondering if anyone else is getting probed via this port as it seams im catching this on several locations and not 100% sure what to do about it.

EDIT:Yes, it serves as honey-pot.

mkx · Tue Sep 18, 2018 4:32 pm

... i was just wondering if anyone else is getting probed via this port as it seams im catching this on several locations and not 100% sure what to do about it.

Could be, but I don't notice as I have a general drop rule at the end of firewall rules list. It does show increasing number of connections/packets involved, but I don't log details so I don't know why they were dropped. Well, I do know they were dropped because it wasn't something I explicitly allowed, but that's all.

ivicask · Tue Sep 18, 2018 4:33 pm

... i was just wondering if anyone else is getting probed via this port as it seams im catching this on several locations and not 100% sure what to do about it.
Could be, but I don't notice as I have a general drop rule at the end of firewall rules list. It does show increasing number of connections/packets involved, but I don't log details so I don't know why they were dropped. Well, I do know they were dropped because it wasn't something I explicitly allowed, but that's all.

Problem is not blocked ports, problem is that we do have 10+ open ports for VPN, RDC etc, and if they already managed penetrate RDC, im afraid they may do it again, so i rather honey-pot them tho it doesnt mean its any 100% protection..

mkx · Tue Sep 18, 2018 4:41 pm

... i was just wondering if anyone else is getting probed via this port as it seams im catching this on several locations and not 100% sure what to do about it.
Could be, but I don't notice as I have a general drop rule at the end of firewall rules list. It does show increasing number of connections/packets involved, but I don't log details so I don't know why they were dropped. Well, I do know they were dropped because it wasn't something I explicitly allowed, but that's all.
Problem is not blocked ports, problem is that we do have 10+ open ports for VPN, RDC etc, and if they already managed penetrate RDC, im afraid they may do it again, so i rather honey-pot them tho it doesnt mean its any 100% protection..

Probably best practice is to limit access to open ports from select public IP addresses/subnets ... if that's feasible to do. E.g. if you only expect to receive RDP or VPN connections from a few remote places, you can explicitly allow connections only from those IP addresses. This greatly narrows probability of attacker bypassing firewall.
If that's not feasible, you could try to implement some port-knocking mechanism (so that in order to "open", say, RDP port, you need to try to open a few other ports in predefined sequence with tight timing in place). This technique is generally not acceptable for "plain" users, but might be fine with some advanced users.
Whatever you pass through firewall you have to secure at the application server (if possible at all).

In short: if it's feasible, deny everything that is not explicitly allowed (default with it's implicit allow all rule is just the opposite).

ivicask · Tue Sep 18, 2018 4:46 pm

... i was just wondering if anyone else is getting probed via this port as it seams im catching this on several locations and not 100% sure what to do about it.
Could be, but I don't notice as I have a general drop rule at the end of firewall rules list. It does show increasing number of connections/packets involved, but I don't log details so I don't know why they were dropped. Well, I do know they were dropped because it wasn't something I explicitly allowed, but that's all.
Problem is not blocked ports, problem is that we do have 10+ open ports for VPN, RDC etc, and if they already managed penetrate RDC, im afraid they may do it again, so i rather honey-pot them tho it doesnt mean its any 100% protection..
Probably best practice is to limit access to open ports from select public IP addresses/subnets ... if that's feasible to do. E.g. if you only expect to receive RDP or VPN connections from a few remote places, you can explicitly allow connections only from those IP addresses. This greatly narrows probability of attacker bypassing firewall.
If that's not feasible, you could try to implement some port-knocking mechanism (so that in order to "open", say, RDP port, you need to try to open a few other ports in predefined sequence with tight timing in place). This technique is generally not acceptable for "plain" users, but might be fine with some advanced users.
Whatever you pass through firewall you have to secure at the application server (if possible at all).

In short: if it's feasible, deny everything that is not explicitly allowed (default with it's implicit allow all rule is just the opposite).

Yes, iv done that with RDP, but i cant do for VPN coz they connect from vairous IP, mobile phones, public hotspots...

nostromog · Tue Sep 18, 2018 5:31 pm

I'm seeing them too. From two different routers:

[admin@MikroTik] > /log print count-only  where message~":60000->"
6

and

[admin@MikroTik] > /log print count-only  where message~":60000->"
14

They are stealth in the sense that they avoid typical blacklisting attempts; just a few contacts per hour coming from different ips. I think basically looking for open ports.

They tried 3389,143,389,3390,9999,3389 in one machine and 3399,8022,3389,33890,1500,222,8083,13389,3395,2222,3391,110. It looks like variants of default service ports of known vulnerable services. Changing the port of a service is usually not the solution to the problem...

One solution to the problem is to close everything except a few service ports (like web server or VPN ports) and a whitelist and then add to it static addresses or even DDNS names, and hack a port knocking script that will add any one "knocking" the right sequence of ports into the whitelist for a while... I'm half way there: I have blacklist/whitelist and ddns, one of this days I'll hack the port knocking stuff and close anything not intended for general consumption.

ivicask · Tue Sep 18, 2018 6:11 pm

I'm seeing them too. From two different routers:
Code: Select all
[admin@MikroTik] > /log print count-only  where message~":60000->"
6
and
Code: Select all
[admin@MikroTik] > /log print count-only  where message~":60000->"
14
They are stealth in the sense that they avoid typical blacklisting attempts; just a few contacts per hour coming from different ips. I think basically looking for open ports.

They tried 3389,143,389,3390,9999,3389 in one machine and 3399,8022,3389,33890,1500,222,8083,13389,3395,2222,3391,110. It looks like variants of default service ports of known vulnerable services. Changing the port of a service is usually not the solution to the problem...

One solution to the problem is to close everything except a few service ports (like web server or VPN ports) and a whitelist and then add to it static addresses or even DDNS names, and hack a port knocking script that will add any one "knocking" the right sequence of ports into the whitelist for a while... I'm half way there: I have blacklist/whitelist and ddns, one of this days I'll hack the port knocking stuff and close anything not intended for general consumption.

Yep, thats pretty much what im also seeing, im thinking could there be some other smart way of adding whitelist IP adresses for most of this services like RDC or VPN in way like script which runs on PC,(scheduler, or scripted bat which updates ip than runs RDC/VPN) and sends IP to some server(FTP or wahtever), and mikrotik than pools that source and refreshes(adds) whitelist adresses which are allowed to acces this services(with certan TTL).Or even simpler some simple dyamic dns service installed to all customer PCS who need acces to RDC/VPN and who have dynamic IP.Dont know just had such idea, what everyone thinks?

Port 60000 attacks, anyone info on this?

Port 60000 attacks, anyone info on this?

Re: Port 60000 attacks, anyone info on this?

Re: Port 60000 attacks, anyone info on this?

Re: Port 60000 attacks, anyone info on this?

Re: Port 60000 attacks, anyone info on this?

Re: Port 60000 attacks, anyone info on this?

Re: Port 60000 attacks, anyone info on this?

Re: Port 60000 attacks, anyone info on this?

Re: Port 60000 attacks, anyone info on this?

Re: Port 60000 attacks, anyone info on this?

Re: Port 60000 attacks, anyone info on this?

Re: Port 60000 attacks, anyone info on this?

Who is online