CastleCops :: View topic - Tracking Spam Source

Tracking Spam Source
Goto page 1, 2 Next
CastleCops -> Spam

Author: i_rod, Location: Canada

Posted: Sat May 10, 2008 12:19 am Post subject: Tracking Spam Source

I'm a long way from being the brightest bulb in the box, so perhaps someone here can stake me to a few lumens.

I've been trying to find an A record and/or canonical address associated with the IP in a spam I got the other day. To whit:

Quote:

Received-SPF: fail (Last token {-all} (res=FAIL)) client-ip=189.31.219.105; envelope-from=<Hanna-thgildee@17.nowstandard.com>; x-ip-name=;

I know this is an open relay, but I've been under the impression that MX accounts still need to map to a cononical address... whereas in this case, “dig -x” doesn't show an answer section for the PTR and of course “host -a” doesn't help either. I think I can query the server(s) at < ns0-bsa.brasiltelecom.net.br>. <dns.brasiltelecom.net.br> <ns03-cta.brasiltelecom.net.br> & <ns04-bsa.brasiltelecom.net.br> but I don't know the drill or even if that is the right way to go.

Obviously, my 'wetware' is lacking here and I would appreciate some guidance.

Author: tembow,

Posted: Sat May 10, 2008 2:43 am Post subject:

Go to http://who.is and type in the address and get
inetnum: 189.30/15
aut-num: AS8167
abuse-c: BTA17
owner: Brasil Telecom S/A - Filial Distrito Federal
ownerid: 076.535.764/0326-90
responsible: Brasil Telecom S. A. - CNRS
owner-c: BTC14
tech-c: BTC14
inetrev: 189.31.192/18
nserver: ns03-cta.brasiltelecom.net.br
nsstat: 20080508 AA
nslastaa: 20080508
nserver: ns04-bsa.brasiltelecom.net.br
nsstat: 20080508 AA
nslastaa: 20080508
created: 20070402
changed: 20070402

nic-hdl-br: BTA17
person: Brasil Telecom S. A - Abuso
e-mail: abuse@noc.brasiltelecom.net.br
created: 20030624
changed: 20050214

nic-hdl-br: BTC14
person: Brasil Telecom S. A. - CNRS
e-mail: suporte@noc.brasiltelecom.net.br
created: 20031003
changed: 20080229

That is the ISP who owns the IP address, and there is the complain-to address for email.

Strictly speaning there is no such thing as "an A record ..... associated with the IP" since the IP is the A. But I know what you mean. You are looking for a name that resolves to the address.

It's better to report the IP to the owner, with your evidence that it is spewing spam.

Author: i_rod, Location: Canada

Posted: Sat May 10, 2008 10:16 am Post subject:

tembow;

Thanks, but I think you missed the point; ...probably because I didn't make it very well. My bad.

I'm not interested in reporting at this point ,,, If I was, I wouldn't use the abuse desk unless I wanted more spam. And I don't have much faith in the “whois” records apropos “registration info” where spam is concerned. I'm just trying to gain some understanding as to what is going on with this and similar spam apropos SMTP.

I had always assumed there was a canonical address, you know... a conventional email address character string... in the DNS zone file on any MTA's server to uniquely identify the sender account. Forged spam headers aside for a moment, in legitimate practice, without an MX record to recursively convert the IP to the email addy and back, it wouldn't be possible to reply to an email; e.g. for a sender's MTA to do the necessary rDNS before attempting to deliver email to that account, like a reply. I had assumed maintaining a valid MX record was 'de rigueur' within SMTP and I also assumed these records were accessible to the general public using standard query techniques.

In this instance:...

Quote:

~$ host -t MX 189.31.219.105
105.219.31.189.in-addr.arpa domain name pointer 189-31-219.ctame700.dsl.brasilte lecom.net.br.

...tells me the sender apparently was using a dial-up connection and SORBS queries tell me this IP has been identified as an Open Relay. What these 'recherches' don't tell me is why no MX record/Host File, no canonical email string is in evidence.

So, among the questions I'm asking myself:
* Why Not?
* Has a <.brasiltelecom.net.br> root server (SOA) been hacked/compromised ?
* Has a PC MUA on a network been hacked and/or had the CNAME aliased, thus breaking the rDNS query?
* How can I assign probabilities as to whether this and similar spam are being vetted by a 'bot', a simple Open Relay or if the IP in question might be a “throw-away” account; i.e. the actual origin?

It's entirely possible this phenomenon has been going on for some time and I've just been overlooking it. In any case, the spamtrap receiving this item doesn't get a lot of hits and I need to know if I need to revise my SQLDb to start accommodating them, or not.

Author: ahoier, Location: USA

Posted: Sat May 10, 2008 4:13 pm Post subject:

I belive "most" spam nowadays is sent using open relays, hijacked hosts, or other hackery methods.

SpamCop is suited for reporting unsolicited spam to ISPs, if that is what you are getting at.

Though yes, I'm sure there are some hosting providers (we called them bullet-proof hosting...usually based in Russia, or other countries that simply don't care) who will not clean up their networks despite the reports you send, though your submissions will keep their IP ranges live on SpamCops blocklists.

Author: s0tet,

Posted: Sat May 10, 2008 4:35 pm Post subject:

The host in question has been hijacked and spam is spewing from the IP: 189.31.219.105

The non-resolving reverse DNS entry indicates to me that it could have been an ADSL account in Brazil that is not in current use. 189-31-219.ctame700.dsl.brasiltelecom.net.br This rDNS to me looks like it is incomplete on purpose (missing the last octet in the IP range). For instance, if you google similar subdomains, such as 189-30-141-251.ctame700.dsl.brasiltelecom.net.br, you will find that this one does resolve to: 189.30.141.251 (at the time of this post).

So when you query 189-31-219.ctame700.dsl.brasiltelecom.net.br, it does not resolve to this IP as you already pointed out.

Spammers will infect anything online, they don't care if there are resolvable rDNS entries or not. According to the RBL quieries I did on this IP, [ example: http://www.robtex.com/rbl/189.31.219.105.html ] it tells me it has spewed a lot of spam and therefore is blacklisted by lists which detect compromised spam origins.

This type of activity has been going on quite a while. Back around 2001 or so, more and more ISPs started blocking email from hosts where the IP and the rDNS entries do not resolve, so this spammers' email is not arriving at many locations, except for recipients who are mostly spamtraps waiting to detect such activity.

Maybe I helped explain this for you, I hope so. You brought up some great questions.

BTW, I learned the word wetware from reading your post, I had never heard of that term. Smile

Author: s0tet,

Posted: Sat May 10, 2008 4:57 pm Post subject:

I forgot to add: I scanned a few ports and found: - Other port: (110 - POP3) (active) so this appears to be active on this host, so the IP is definitely open relayed or it is some sort of hijacked host used for mailing spam.

Author: i_rod, Location: Canada

Posted: Sun May 11, 2008 10:47 am Post subject:

s0tet:

Hi; at last, some traction.

I looked at that dang rDNS for hours thinking “.ctame700” indicated a <.br> network CNAME/alias instead of taking it at face value as you so wisely did;... good eye. My dumb.

I'd polled all the RBLs before I made my OP; ... standard practice on my system. Often SC or Spamhaus publish histories on Open Relays that have been around for a while. It's in the PBL of course [PBL190804]; but even SH didn't seem to have bothered to resolve it.

What I'm trying to understand, specifically and for future reference, is: if the <.br> server has been compromised, which we agree does seem to be the case, wouldn't all the subdomains on that server, in that zone, be “munged” as well; which would (should?) mean we couldn't query them either? Since we've established that they do resolve, I'm puzzled as to just how only one “A” record, or one MX record seems to be affected. I don't think it would be worth while to code the virus for only one account; do you? And if the "worm" has a "spreader", then eventually, all the clients on that <.br> net would get taken down: i.e., become unreachable/unresolvable. That would be counter-productive from a spammer's POV. Whether or not it's a dial-up (as we might infer from the string section <.dsl.brasiltelecom.net.br> shouldn't matter as far as I can tell.

Just to remind you, I'm not the brightest bulb in the box. But I can see how the PC on this <.br> ADSL can be infected, be part of a bot herd and have all manner of misconfigurations in it's mail client; thereby rendering its SMTP stamps suspect. Still; if it exists, there has to be a canonical address to identify it on the internet. So where is it?

If [189.31.219.105] is confirmed to be listening on 110 then we can assume it does exist; i.e., is in current use. Or am I wrong?
I tried Ping and Traceroute a couple of times without success

Quote:

15 BrT-G1-0-0-700-ctame700.brasiltelecom.net.br (201.10.217.6) 260.129 ms 252.982 ms 258.833 ms

But I'll take your word that your port scan brought joy.

So how does this PC route/relay mail (Port 25 ?) through the <.br> server and have it stamped with a bogus/munged DNS signature? And how would/does the purported “botmiester” contact the PC to give it new instructions? Without the recursive (unmunged) MX record, neither the <.br> server nor the infected PC would be able to recognize one another. I maybe wrong, but I don't think a port scan would work either unless the signal was routed through the <.br> server to the slave PC.

Quote:

...so this spammers' email is not arriving at many locations, except for recipients who are mostly spamtraps waiting to detect such activity.

Hmmm; I hope this one of mine hasn't been “outed” and some 'shadenfreuden' is just winding me up for the fun of it. It wouldn't be the first time.

I realize I'm raising a lot of questions here and I don't expect you to tackle them all. But any little bit would be appreciated.

Author: ahoier, Location: USA

Posted: Sun May 11, 2008 3:09 pm Post subject:

No worries with all the questions, this port stuff is kinda new for me too.

From what I've understood, these worms/trojans aren't manufactured "per system" - that would be too much work.

The way the systems are set up, is they contain a minimalist SMTP/mail server to allow outgoing mail.

Quote:

What I'm trying to understand, specifically and for future reference, is: if the <.br> server has been compromised, which we agree does seem to be the case, wouldn't all the subdomains on that server, in that zone, be “munged” as well; which would (should?) mean we couldn't query them either?

The whole .br top-level domain is not infected, the spam is merely originating from a single address/rDNS within the .br network Smile

AFAIK anyways....

Though, who knows, in this day and age of NATs and such, there could possibly BE 10+ machines behind that "IP address"/rDNS. Example: I have a DSL line through HellSouth, I have one IP address, using a wireless router, I have 2 other desktops, one laptop, PLUS the computer directly connected to the router/WAN link, so I have 4 computers totally, running off my IP address.

As far as sending new instructions, I don't think they use mail/smtp to issue new instructions to infected bots, I think most of these bots are sent messages over IRC, or some other protocol, I've read some articles which mention "Freenet" - which is a sort of encrypted Internet...it's a "real" network, not "intended" for use by spammers/criminals, but they have found a use for it...

Freenet http://freenetproject.org/
Freenet on Wikipedia: http://en.wikipedia.org/wiki/Freenet

There are other sites that do extensive research on these botnets too, but that's sorta out of the scope of CastleCops Wink

Though, reading into all this is pretty interesting and quite eye-opening/mind-boggling.

Author: s0tet,

Posted: Sun May 11, 2008 3:32 pm Post subject:

Just as you state, this host is offline now, so no more probing can be done. Smile

Quote:

Because the PTR for this IP didn't resolve correctly, we don't know how many A records or IPs the host even have. On our end, without inside knowledge of the Brasil Telecom setup, is hard for us to tell how many IPs are assigned per host. I couldn't tell what OS the host had even running the few probes that I did.
[EDIT] - ahoier covered some things I didn't in his recent post.

I am guessing the telecom received enough complaints to pull the compromised host offline.

Author: tembow,

Posted: Mon May 12, 2008 11:58 am Post subject:

Quote:

I had always assumed there was a canonical address, you know... a conventional email address character string... in the DNS zone file on any MTA's server to uniquely identify the sender account.

A canonical name - to use your terminology as you have defined it, may or may not have an IP address associated with it. The association between a name and an IP address is created in a DNS "A" record.
[Strictly speaking, a canonical name is an alias for another name. expressed via a "CNAME" record].

An IP address may or may not have a name associated with it. The association is created by the Reverse IP record, know as the PTR. If the PTR exists and is correctly defined, then one can perform a lookup from the IP address to the associated name.

The process of sending an email does not require any valid name being provided by the sender. It is whatever domain name the sender cares to provide.
The receiving system will usully perform a reverse PTR lookup and record the result (if any) in the message header.

Author: i_rod, Location: Canada

Posted: Mon May 12, 2008 4:48 pm Post subject:

s0tet

I 'm sure there's a simple answer to all this; I'm just too confused to frame the right question.

My 'provisional' & hypothetical understanding runs something like:
There's a compromised irc server out there that 'controls' (by proxy) a chat client's Windows PC, (hereinafter called “the W-bot”) which runs a client email program that is hosted on servers on the <.br> dial-up network. The W-bot may be infected by a rootkit virus or a worm that either operate directly on the client email app, or independently as a small SMTP mail app that runs in the background. Either way, the W-bot must have a host domain, a FQDN and/or bracketed quad IP, the record of which must exist in an MX recursive file somewhere on a <.br> SOA server.

Given, some Windows rootkits will connect to the IRC server every time the unit is powered up; even without the operator intending to or being aware of it. But for this to happen, the host server on the <.br> net must recognize the W-bot and resolve its domain both as a valid FQDN and IP bracelet 'before' sending the HELO to the IRC server. Otherwise, the IRC server can't return a SMTP greeting and the connection will fail; the 'host' wouldn't be recognized.

I realize that the IRC server can 'recognize' the IP quad and resolve that to the client's IRC account record. But, this still implies a comprehensive host record, including the MX record, be reposed somewhere on a <.br> server.

I base this 'implication' on my understanding of IRC rooms, (e.g., freenode), in that they permit client email exchanges under various protocols... an option not possible unless a canonical address is “active” for both parties, including this W-bot, and unless both parties are, shall I say, “RFC compliant”.

Which brings us back to the question: where is this FQDM to which [189.31.219.105] doesn't seem to want to resolve using rDNS?

s0tet;
Going back to:

Quote:

The non-resolving reverse DNS entry indicates to me that it could have been an ADSL account in Brazil that is not in current use. 189-31-219.ctame700.dsl.brasiltelecom.net.br This rDNS to me looks like it is incomplete on purpose (missing the last octet in the IP range). For instance, if you google similar subdomains, such as 189-30-141-251.ctame700.dsl.brasiltelecom.net.br, you will find that this one does resolve to: 189.30.141.251 (at the time of this post).

I went back to SC/Ironport: http://www.senderbase.org/senderbase_queries/detailip?search_string=189.31.219.105
to take another look at the address block [189.31.219.0/24] . Based on a random sample of 10, I found that they all return to 189-31-219.ctame700.dsl.brasiltelecom.net.br. I'm not so sure we fully understand just what this sequence means. It could be kosher.... just “news to me”, as the saying goes. Any further thoughts?

Quote:

I couldn't tell what OS the host had even running the few probes that I did.

I tried that too (per Netcraft) but assumed that since ping and traceroute weren't successful, the OS probe had nothing with which to connect; eh?

Quote:

I am guessing the telecom received enough complaints to pull the compromised host offline.

According to Ironport, [189.31.219.105] was first reported 2008-03-17. Given the uncertainties of how quickly the Brazilians respond to complaints, it's very possible it was 'taken down'. But that would be 'contraindicated' by your having successfully done the port scan... well after the rDNS queries failed.

Just FYI for those with exceptionally high thresholds of boredom, here's a graphic on a botnet that was referenced on Slashdot the other day:
http://www.csoonline.com/article/348317/What_a_Botnet_Looks_Like

I got a lot out of a this paper too: “Know Your Enemy; Tracking Botnets”
http://www.honeynet.org/papers/bots/

Author: moike,

Posted: Tue May 13, 2008 3:45 am Post subject:

+1 on tembow's last message: The PTR record is optional; it exists in this case as 189-31-219.ctame700.dsl.brasiltelecom.net.br . This name is created by the network administrator - which may or may not be the same organization as the owner of a server.

i_rod wrote:

My 'provisional' & hypothetical understanding runs something like:

Either way, the W-bot must have a host domain, a FQDN and/or bracketed quad IP, the record of which must exist in an MX recursive file somewhere on a <.br> SOA server.

You may be thinking of SMTP best practices, which require a PTR record, and a forward resolution of the PTR record that matches the IP address. A bot however, does not require anything to send an SMTP message - it can function on a bare IP address with no PTR record. This will raise some flags with spam filtering software on mail servers. The bot / spam proxy can forge any header it wishes in an attempt to appear legitimate, but these attempts also raise spam filtering warning flags.

i_rod wrote:

Given, some Windows rootkits will connect to the IRC server every time the unit is powered up; even without the operator intending to or being aware of it. But for this to happen, the host server on the <.br> net must recognize the W-bot and resolve its domain both as a valid FQDN and IP bracelet 'before' sending the HELO to the IRC server. Otherwise, the IRC server can't return a SMTP greeting and the connection will fail; the 'host' wouldn't be recognized.

Strictly speaking, IRC does not require any PTR record for a client (W Bot in this case) to connect and log in, because it logs in based on uname / handle / password / channel. Again, you may be thinking of IRC best practices for servers, particularly an IRC vhost.

i_rod wrote:

All that is happening here is that the network administrator just likely used a single name for all the addresses in that address block. It would be possible for them to assign a different PTR names for some of the IP addresses in that address block if they needed to.

In summary, everything appears in order with the setup of this particular IP. The PTR record conveys very little additional information and is of little importance to this case.

Also, a tidbit to keep in mind: a corrupt network administrator can put whatever name they wish for a PTR record - including mail.yahoo.com for example. Of course that would bring down the lawyers for the faked organization. Routine receiving SMTP server antispam tests will catch this case. That's why abuse reporting methods favor IP Whois / ASN responsible to identify an abuse contact. PTR records can sometimes help fill in pieces of the puzzle about a host, but I don't rely on them for more than a hint of information.

Author: tembow,

Posted: Wed May 14, 2008 10:45 pm Post subject:

Either way, the W-bot must have a host domain, a FQDN and/or bracketed quad IP, the record of which must exist in an MX recursive file somewhere on a <.br> SOA server.

That is the basic misconception that is causing you such grief. It is simply not true. MX records are involved in the RECEIVING of email by a mail server. SENDING from an IP address does not have to have any name, canonical or otherwise, associated with it.

Your use of the term "canonical" is also not in keeping with the strict definition of the term, thus causing further confusion. A canonical name, also called a CNAME, is an alias for another name.

If there is a name associated with an IP, it is whatever is stored in an Internet database by its owner or delegated owner. It can be as misleading or as accurate as the owner decides it should be.

Author: i_rod, Location: Canada

Posted: Fri May 16, 2008 1:47 am Post subject:

tembow, s0tet, ahoier, moike;

I can't ell you how much I appreciate all the help. (Genuflects 3 times saying, “I'm not worthy ...”.

tembow wrote;

Quote:

”Your use of the term "canonical" is also not in keeping with the strict definition of the term, thus causing further confusion. A canonical name, also called a CNAME, is an alias for another name.”
<snip>
[Strictly speaking, a canonical name is an alias for another name. expressed via a "CNAME" record].

Are you sure... “Strickly speaking”?

From: http://www.domainavenue.com/cname.htm

Quote:

CNAME records simply allow a machine to be known by more than one hostname. There must always be an A record for the machine before aliases can be added. The host name of a machine that is stated in an A record is called the canonical, or official name of the machine. Other records should point to the canonical name.

(Underlines not in original text)

Also: the query “canonical name” in Wikipedia brings ”FQDN” as the first entry; ...suggesting to me some academics are seeing the same thing, the “official name = cannonical name = FQDN”, when when referencing the common usage of the terms.

Quote:

That is the basic misconception that is causing you such grief. It is simply not true. MX records are involved in the RECEIVING of email by a mail server. SENDING from an IP address does not have to have any name, canonical or otherwise, associated with it.

To the extent my MTA's server attempts to 'engage' the sender's server's DNS records as 'de regueure' part of the SMTP Greeting would suggest to me the MX records are 'involved', at least on my system. And since my understanding is that the sender's MX records are, at least ideally/technically, part of his DNS record, I'm kind of stuck on what to make of “MX records are [not] involved”. Or am I just picking nits? I assume this (attempted) engagement takes place; it's recorded in the “Received-SPF:” line as "...x-ip-name=;" showing a non-reply. The issue seems to be whether or not the rDNS succeeds, and if not; why?.

You have a working and respectable understanding of how to reconcile academic vs. practical aspects of this issue. Perhaps you could take a look at this excerpt from “rtknet” and help me catch up a bit.

http://www.rtknet.org/reverseDNSlookup.php

Quote:

Why do reverse DNS lookup failures occur?
Every Internet computer has a numeric "internet protocol" (IP) address which uniquely identifies that computer in the world-wide Internet. There is also a DNS computer officially assigned for every block of IP numbers, whose job is to translate those IP numbers into hostnames and back again.
IP addresses (which look like 123.456.789.012) can be assigned to a caller's workstation permanently or just for the duration of an internet session -- such as the home computer of an AOL user. Either type of IP address will work fine on RTK NET -- so long as the caller's IP number can be verified (from its DNS computer) when the call is received.
When somebody calls our database computer, the calling computer puts its IP number in the call. Our computer asks the official DNS computer to verify that IP number, through a process known as "reverse dns lookup": Our computer asks the DNS computer for the "hostname"associated with the calling IP number and for the IP address associated with that name.
If the DNS computer sends back answers that don't match (or no answer), our computer doesn't know where to send the caller's database search results!
And when a caller's computer receives no response from ours, some web browsers report it as "document contains no data" or "remote server error." Most likely such reports just mean that the caller's pc/workstation has an unlisted IP address -- hidden behind a company "firewall" or behind a DNS computer which has no IP address listing for the workstation.

Perhaps the basic question I'm struggling to ask might go something like: “Is it 'feasible' that the host server in this instance [ref: IP 189.31.219.105, 189-31-219.ctame700.dsl.brasiltelecom.net.br] has been compromised in such a way to interdict rDNS queries for 'M-bot' PCs on that network even though MX records do exist for those PCs?

p.s. tembow; ... congrats on installing the new hardware and getting the board back up.

Author: tembow,

Posted: Fri May 16, 2008 6:32 am Post subject:

OK. I retract on the strict definition of canonical name (mea culpa, mea maxima culpa)

When you run a DNS service, you put in to a zone file a number of records pertaining to the domain.

eg
SOA - the start record
A - the address record (translates a name to an address
CNAME - the canonical name or alias - translates a name to a name
TXT - textual information

So I can have an SOA that contains some overall information followed by
example.com. IN A 123.1.2.3
www CNAME example.com.
ftp CNAME example.com.
maila IN A 123.4.4.4
mailb IN A 123.5.5.5
example.com. MX 10 maila
example.com MX 20 mailb

When anyone looks to find www.example.com. the DNS server finds that it can not return the address, just the canonical name example.com. So www.example.com is the alias for the canonical name example.com, as implemented by the CNAME record.

An automated second query on example.com returns the IP address.

That is the strict DNS definition of the terminology that refers to the actual DNS records.

I was confused, and applied the term to the alias, rather than the name the alias resolves to.

Now to the second point

If you want to pursue how an email SENDER can send an email with absolutely any source name, look up how to telnet to port 25 of a mail server. Note how it prompts you for a name. You can key any name.
It is a function of rules within the name server to perform any verification at that point.

Loosely configured servers will take anything. More tightly configured servers may perform a check to see if the sender domain or email address exists before proceeding. More tightly configured will perform a PTR reverse IP lookup. More tightly still will compare the PTR with the user provided, and filter out on bad matches. More tightly again will process SPF checks before allowing a message.

Telnet hostname port.
For the "Host Name", enter the mail server name (for example, "mail.example.com"). For the Port, enter 25. A second or two later you should see a welcome message. Type "HELO" followed by the domain name of the computer you are using. For example, "HELO mail.example.com". Then, after you get a response, type "MAIL FROM: my.email.address@example.com" (using your E-mail address on your mail server), and then "RCPT TO: my.email.address@example.com". Then, type "DATA", "Subject: Test", a blank line, "Test", and then ".". After the response, type QUIT.

If you lie about the domain name, and you lie about the MAIL FROM, you will get different success rates with differently configured mail exchanges.

By the way, if your service provider blocks you from doing a telnet on port 25, you will not be able to conduct that test. Port 25 blocking is becoming a prevalent measure among ISPs to prevent spam from direct mailers.

CastleCops -> Spam

All times are GMT

Goto page 1, 2 Next Page 1 of 2