UDP Port 18273

[fukawi2]

Does anyone have any idea what UDP port 18273 is? I'm seeing an
unusually large amount of blocks on my firewall for this. I find it
strange for several reasons:
1) It's UDP 18273.
2) There's over 2000 blocks for it already this week.
3) It's from all over the world, not just one source.

Just this week:
3 SRC=109.110.83.26
3 SRC=109.89.12.169
3 SRC=156.26.118.151
3 SRC=193.136.129.191
174 SRC=213.88.78.9
66 SRC=2.36.48.163
3 SRC=41.121.28.166
117 SRC=78.134.48.165
218 SRC=79.16.16.15
18 SRC=79.25.116.103
9 SRC=79.27.13.120
3 SRC=79.55.85.213
3 SRC=80.181.72.49
188 SRC=80.68.181.94
3 SRC=80.86.125.14
3 SRC=81.165.118.247
166 SRC=82.56.62.209
34 SRC=83.211.66.28
9 SRC=85.230.4.24
337 SRC=87.1.123.171
99 SRC=87.1.231.85
299 SRC=87.19.62.228
3 SRC=87.4.233.216
33 SRC=87.8.95.129
11 SRC=93.145.209.241
202 SRC=93.146.150.147

Traffic capture of some of the packets doesn't reveal anything
interesting:
http://ompldr.org/vNnJ5Zw/udp18273.pcap

[Mark H]

The only reference I can think of is a bittorrent client perhaps?
if you have a dynamic IP address for your service it is likely that
the previous owner was using torrent and that the IP is still
registered with some tracking servers. what you may be seeing is this
type of traffic trying to reach the torrent client.

regards

Mark

> --
> Need IPv6 Training? See http://www.ipv6securitytraining.com . IPv6 Security Training
>
> To unsubscribe from this group, send email to
> iscdshield+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/iscdshield?hl=en
>

--

Note: The handlers are a group of about 30 volunteer computer security
professionals.  You may receive responses from several individuals.
Please, use 'reply-to-all' to keep everyone in the loop.

[Phillip Smith]

On 30 December 2010 10:21, Mark H <mark...@gmail.com> wrote:

The only reference I can think of is a bittorrent client perhaps?
if you have a dynamic IP address for your service it is likely that
the previous owner was using torrent and that the IP is still
registered with some tracking servers.  what you may be seeing is this
type of traffic trying to reach the torrent client.

That was all I can think of, but:

a) This is a static address

b) There is no outbound torrent traffic (that I can detect anyway!) 

[Miguel Angel Cantú Sauceda]

By the number of src ip's could be a customized port generated for p2p sharing files for control for availability sharing distributed files, may be, cause I was experiencing that with some customers with different ports and the problem was a software p2p installed that broadcast udp traffic, I could be sure, cause many of the ips are dynamic and/or not assigned reverse dns resolution.


mcan...@alestra.com.mx
www.alestra.com.mx


--
Need IPv6 Training? See http://www.ipv6securitytraining.com . IPv6 Security Training

To unsubscribe from this group, send email to
iscdshield+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/iscdshield?hl=en

NOTA: La información de este correo es de propiedad exclusiva y confidencial. Este mensaje es sólo para el destinatario señalado, si usted no lo es, destrúyalo de inmediato. Ninguna información aquí contenida debe ser entendida como dada o avalada por Alestra, sus subsidiarias o sus empleados, salvo cuando ello expresamente se indique. Es responsabilidad de quien recibe este correo de asegurarse que esté libre de virus, por lo tanto ni Alestra, sus subsidiarias ni sus empleados aceptan responsabilidad alguna.

NOTE: The information in this email is proprietary and confidential. This message is for the designated recipient only, if you are not the intended recipient, you should destroy it immediately. Any information in this message shall not be understood as given or endorsed by Alestra, its subsidiaries or their employees, unless expressly so stated. It is the responsibility of the recipient to ensure that this email is virus free, therefore neither Alestra, its subsidiaries nor their employees accept any responsibility.

[Tom Byrnes]

None of these IPs show up (ever, in the last 4 years) in any of the
feeds we pull @ ThreatSTOP, although some of them are recently assigned
(were bogons until early this year).

Doesn't mean that the traffic is NOT malicious, just that the sources
haven't been detected by any of the major IP rep feeds, which means
either you're very special, it's very new, or it's background noise.

> -----Original Message-----
> From: iscds...@googlegroups.com [mailto:iscds...@googlegroups.com]
> On Behalf Of fukawi2
> Sent: Wednesday, December 29, 2010 2:22 PM
> To: SANS Internet Storm Center / DShield
> Subject: [dshield] UDP Port 18273
>

[Gibson, Joseph D]

Sort of a shift in topic...

VM clone your works and have outbound go into a dead zone. Release all ports and see of those pop up and provide clues. I'm as interested in the anomaly as well as a potential sec breach. It's of course common for someone to exploit, then fix it do know one else can join the party.

Outbound can look completely innocent depending on what you read it with and how many books you've read on the sports/subject.

JG

Sent from my Samsung Epic™ 4G aboard the Starship Enterprise

[Phillip Smith]

On 30 December 2010 12:35, Tom Byrnes <to...@threatstop.com> wrote:

None of these IPs show up (ever, in the last 4 years) in any of the
feeds we pull @ ThreatSTOP, although some of them are recently assigned
(were bogons until early this year).

Doesn't mean that the traffic is NOT malicious, just that the sources
haven't been detected by any of the major IP rep feeds, which means
either you're very special, it's very new, or it's background noise.

Thanks for the input everyone... I don't see us being very special, but the lack of information Google gave me made me curious... And it stands out above the noise, which is why I noticed it. I initially thought it have have been related to the new production line we recently installed (from Italy) due to the number of hits from ".it" addresses, but that company doesn't know anything about it, and the number of other countries apart from Italy have increased.

I'll continue to monitor and see if anything new comes up.

[Tom Byrnes]

Easier way to do this, assuming he has a vm environment, would be to put his WS behind a Vyatta VM in bridge mode, and run a ThreatSTOP trial to see if he's connecting to any known C&Cs. If he is, then OOPS. If not, then he could set up block and log rules for the sort of traffic he wants to inspect, and see if it gets hit.

[Phillip Smith]

On 30 December 2010 12:48, Gibson, Joseph D <jodg...@indiana.edu> wrote:

Sort of a shift in topic...

VM clone your works and have outbound go into a dead zone.  Release all ports and see of those pop up and provide clues.  I'm as interested in the anomaly as well as a potential sec breach.  It's of course common for someone to exploit, then fix it do know one else can join the party.

You give us too much credit!

I only took over as IT Manager/CTO at the start of November, so I'm still trying to get VM infrastructure in place. I've managed to get a central firewall in place, but everything from LEG to NET (LEG = Legacy Network) is still wide open outbound.

My last job was at a company specializing in Network Security for places like Toyota, BMW and other large organizations -- not saying I know everything, but I've got a good idea what to be looking for -- nothing outbound looks too suspicious at the moment (somehow!).

[Tom Byrnes]

Which “production line” stuff did you install?

 

SCADA worms are relatively new, so you MAY have something we haven’t seen before.

 

 

 

--

[Mike Zarins]

I double Joseph's response. Got to release the traffic for it to make a round trip to provide clues and perhaps trigger the signature on your IPS/IDS; assuming traffic flows through IPS/IDS.

Keep posted, I'm curious to find out.

Sent from iPhone

[Phillip Smith]

On 30 December 2010 13:15, Tom Byrnes <to...@threatstop.com> wrote:

Which “production line” stuff did you install?

 

SCADA worms are relatively new, so you MAY have something we haven’t seen before.

I don't know much about it -- it is from "ItalProject" (http://www.italproject.net/) if that helps. The most I know is that it's got various components that need network, including PLC's, and it generates a LOT of network traffic when the line is running, mainly multicast.

The whole production line sits on it's own Layer 2 behind an internal Cisco 1720. (I started this job just in time to isolate it!).

Any packets the primary firewall sees from PRD to NET gets logged and dropped. Nothing seen from it:

Chain crs_PRD_NET (1 references)

 pkts bytes target     prot opt in     out     source               destination         

    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `[crs_PRD_NET] ' 

    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

# grep crs_PRD_NET /var/log/messages 

# zgrep crs_PRD_NET /var/log/archive/messages.*

#

[Gibson, Joseph D]

Good idea. I always forget the easier routes because our NOC is separate. I'd love to have span port or whatever to set up an IDS for just my Dept. No go.

In this case though, and magical funds appear I think I'd go for a professional audit. Depending what's at stake, secrets or rep, I'd have to know. If I wasn't satisfied, I'd rebuild. A torrent can include anything in code. If that seems to be the obvious suspect here, consider your computer public property.

J

[Phillip Smith]

On 30 December 2010 13:32, Mike Zarins <mike....@gmail.com> wrote:

I double Joseph's response. Got to release the traffic for it to make a round trip to provide clues and perhaps trigger the signature on your IPS/IDS; assuming traffic flows through IPS/IDS.

Thing is, I don't know where to 'release' it to -- it's destined for the firewall itself (ie, the address used to SNAT all outbound traffic).

I don't see any outbound traffic on this port, so I'm waiting for the next block to dump anything to/from the source host to see if I can catch another port, or ports.

[Tom Byrnes]

From some side conversations I’ve had, this could be a new conficker variant. Those UDP packets would be drones scanning.

 

The most effective way to disrupt conficker, or any fast-flux DNS bot for that matter, is to block requests to the nameservers for the parent domain (the TLD that conficker generates the pseudorandom hosts in). This generally also works for randomly generated “tasted” TLDs, because the weakness of this malware approach is that, thanks to the short TTL of the actual host records, the botmasters need to use relatively stable NS records, since the CNAME/A records are unlikely to be cached. They can’t use hosted DNS services, since they have to be able to update the host IPs pretty often, and any DDNS provider would catch them fairly quickly. So, short of a gtld/cctld operator being in on the game, or compromised (in which case, just block that operator’s nameservers), you can block a wide range of badness by just blocking the known nameservers used by their zones. Beware if you are using forwarders (or, in theory, any other proxy DNS, although OpenDNS and others are pretty good at actually blocking/redirecting the fast-flux domains quickly), as this protection method will fail.

 

You’ll still have to find the drones, and identifying them will usually require analyzing your DNS server logs (for SERVFAIL, when the DNS request to the NS for the A times out due to the blocks), but it’s better than having a bot army on your network that are all able to talk to their herders.

 

 

Of course, even if you ARE using OpenDNS or other DNS proxies, (or are on the bleeding edge with RPZ feeds in your own nameservers) many bots, including later conficker variants, redirect all DNS requests on infected hosts directly to their pwned nameservers, rendering that method of protection moot. Blocking those pwned nameservers in your IDP or firewall, however, DOES protect you, with the added advantage that the trojaned user will call the helpdesk wondering why they can’t browse the web.

 

ThreatSTOP provides a significant number of these known NS IPs in our lists, and we are working on adding to them all the time. We’ve become members of the Security Information Exchange @ ISC, and our server there will be pulling data on these botnets, as well as sharing data with others.

 

Analysis of logs we’ve received over the past 2 days show a lot more blocks on outbound DNS requests to IPs we block, which usually means a new botnet went active. Most of these Nameservers are in China, and a good number of them are in the various DShield lists (many in the top 4000, which should only be used in conjunction with a whitelist of critical nameservers you don’t ever want to block).

 

From: iscds...@googlegroups.com [mailto:iscds...@googlegroups.com] On Behalf Of Phillip Smith
Sent: Thursday, December 30, 2010 2:35 PM
To: iscds...@googlegroups.com
Subject: Re: [dshield] UDP Port 18273

 

On 30 December 2010 13:32, Mike Zarins <mike....@gmail.com> wrote:

--

[Tom Byrnes]

Since you’re not seeing outbound traffic on this port, if you DO have bots in your network, they are probably using HTTP(s), and these UDP packets are return connection attempts.

 

It’s also possible that it’s just scans, and you aren’t infected.

 

Easiest way to find out is profile your outbound traffic and compare to some earlier baseline.

 

 

 

From: iscds...@googlegroups.com [mailto:iscds...@googlegroups.com] On Behalf Of Phillip Smith
Sent: Thursday, December 30, 2010 2:35 PM
To: iscds...@googlegroups.com
Subject: Re: [dshield] UDP Port 18273

 

On 30 December 2010 13:32, Mike Zarins <mike....@gmail.com> wrote:

--

[Frank Knobbe]

On Wed, 2010-12-29 at 14:22 -0800, fukawi2 wrote:
> Does anyone have any idea what UDP port 18273 is? I'm seeing an
> unusually large amount of blocks on my firewall for this. I find it
> strange for several reasons:
> 1) It's UDP 18273.
> 2) There's over 2000 blocks for it already this week.
> 3) It's from all over the world, not just one source.

This is likely NOT Conficker as surmised in other emails. We have
observed unsolicited UDP packets to IP addresses that were never used by
workstations or NAT/firewalls. In fact, some of the IP addresses
receiving these unsolicited UDP packets have been occupied by intrusion
detection systems for nearly a decade.

Capture a packet using ngrep. If you see "e1:q4:ping1:t4:" or similar,
those are Bittorrent Pings. If the packet starts with "d1:ad2:id20:" or
similar, you're also dealing with Bittorrent requests. We've seen those
unsolicited P2P pings also to IPs that never had workstations on it
(either are unused for years, or are used by our IDSes).

That said, we've also observed other unsolicited UDP packets--again to
unused, tarpit, darknet or IDS IP addresses--that don't seem to match
any P2P protocols or SIP. Some of these ports are 54756, 56814, 37556,
20587, 34044, etc, etc.

Since the port numbers vary to greatly, it's unlikely these are botnet
CNC scans. Some ports do stick out, like 16769 and 34044, in that there
are retries of those packets. None of these source IPs belong to known
botnet controllers, but almost all of these sources are residential
cable/DSL addresses. A good chunk of those sources are also performing
TCP scans against the same ports. Odd, eh?

But overall I believe these are caused by crappy P2P applications that
are just nuts and try to connect to world and dog.

Cheers,
Frank

[Valdis.K...@vt.edu]

On Sat, 01 Jan 2011 16:49:48 CST, Frank Knobbe said:
> But overall I believe these are caused by crappy P2P applications that
> are just nuts and try to connect to world and dog.

And sometimes, the P2P application is behaving as sanely as it is able to, when
it is intentionally lied to about who is a member of the set "world and dog".

The various copyright-mafia groups *have* been known to hire enforcers who
intentionally polluted the P2P trackers with IP addresses that were in fact not
seeding the files. The *real* fun started when some *other* enforcer didn't
know what the first group was doing, and started sending out 512-takedown
requests on the basis of the bogus seeding entries on the trackers.

[Phillip Smith]

On 31 December 2010 13:03, Tom Byrnes <to...@threatstop.com> wrote:

Since you’re not seeing outbound traffic on this port, if you DO have bots in your network, they are probably using HTTP(s), and these UDP packets are return connection attempts.

 

It’s also possible that it’s just scans, and you aren’t infected.

 

Easiest way to find out is profile your outbound traffic and compare to some earlier baseline.

I don't have a baseline to compare to unfortunately... :(

A proxy server is on it's way shortly, so once that is in place I will be able to shutdown outbound HTTP(s) outbound NAT traffic which should hopefully reveal a lot of things, maybe related to this, and almost certainly not related to this!

I've setup a nc process listening on 18273 and another tcpdump to see if I can garnish any extra information, but I doubt it since I don't know what the other end is expecting me to respond with.

Cheers,

~p 

[Tom Byrnes]

Just ZFYI, a TS user who uses ThreatSTOP in their corporate offices, but
not in their co-lo, just got a fresh conficker B (per Vipre rescue)
infestation in their co-lo, but not @ their offices.

Looks like conficker may be going active again.

> -----Original Message-----
> From: iscds...@googlegroups.com [mailto:iscds...@googlegroups.com]
> On Behalf Of Frank Knobbe
> Sent: Saturday, January 01, 2011 2:50 PM
> To: iscds...@googlegroups.com
> Subject: Re: [dshield] UDP Port 18273
>

[Frank Knobbe]

On Mon, 2011-01-03 at 15:09 -0800, Tom Byrnes wrote:
> Just ZFYI, a TS user who uses ThreatSTOP in their corporate offices, but
> not in their co-lo, just got a fresh conficker B (per Vipre rescue)
> infestation in their co-lo, but not @ their offices.
>
> Looks like conficker may be going active again.

Conficker is active, no doubt about that. Or at least something like it.
We've seen an immense increase on port 445 attempts (it's topping our
charts for while now. Didn't follow closed with the holidays and all,
but looks like at least a week).

What I'm saying is that those packets the OP described don't look like
Conficker.

-Frank