Hunting for bogons and the ISPs that announce them

In the coming weeks, I will be monitoring bogons in the wild and the ISPs that announce them. But first, what the heck is a bogon anyway? Bogon is an informal term used to describe IP packets on the public Internet that claim to be from an area of the IP address space reserved, but not yet allocated or delegated by the Internet Assigned Numbers Authority (IANA) or any of the Regional Internet Registries (RIR).

Many ISPs filter bogon ranges, because they have no legitimate use traversing the internet. If you find a bogon in your firewall logs it is likely due to someone either accidentally misconfiguring something or intentionally creating them for malicious purposes.

Bogons may change to legitimate source IPs over time as they are allocated and assigned by IANA or a RIR, meaning there is no static list of bogons. A current list of all IPv4 prefixes that have been allocated or not by IANA can be found here. Only Martians will remain forever on the bogon list.

Marvin the Martian
© Warner Bros.

No, not that Martian. In IP networking, Martians are packets with source or destination addresses within special-use ranges such as:

Address block Present use
0.0.0.0/8 “This” network[5]
10.0.0.0/8 Private-use networks (Class A)[6]
100.64.0.0/10 Carrier-grade NAT[7]
127.0.0.0/8 Loopback[5]
169.254.0.0/16 Link local[9]
172.16.0.0/12 Private-use networks (Class B)[6]
192.168.0.0/16 Private-use networks (Class C)[6]
224.0.0.0/4 Multicast[13]

Now that we have a basic definition of a bogon established, where can we find an up-to-date list of bogon IP ranges? The only recently updated list I could find was provided by Country IP Blocks and they offered a complete bogon list in eleven different ACL Formats.

So how do we locate ISPs letting bogons onto the internet? Luckily this is easy as visiting Hurricane Electric’s Bogon Routes page.

M247 Ltd

One such ISP I found was M247 Ltd (previously known as GlobalAXS Communications).  I contacted them on July 11 and asked for comment.  I didn’t receive a follow up until July 24 when an unnamed M247 support representative stated:

As you can see from the HE site we are no longer announcing these prefixes. I am not authorised to comment any further.

I again asked if someone was authorized to comment further and received the following update on July 27:

I have spoken to our management who have authorised me to give you a further statement.

This was accidental misconfiguration on one of our devices which meant that some RFC1918 prefixes [private IP addresses] were tagged with our announce community. This has been rectified and the member of staff responsible re-trained.

 

High volume of Protocol 47 (GRE) traffic from HiNet (AS3462) found

I’ve been monitoring protocol 47 traffic for the last six months and found a clear trend from one internet service provider, HiNet (AS3462). Protocol 47 is the Assigned Internet Protocol Number for Generic Routing Encapsulation (GRE).  GRE is a tunneling protocol developed by Cisco Systems that can encapsulate a wide variety of network protocols inside virtual point-to-point links over an IP network.

The summary of the data I collected, grouped by city and sorted by traffic volume, is noted below:

Protocol 47 (GRE) traffic observed

The raw data collected, listing each IP address and timestamp, can be found here.

Example uses of GRE include:

  • In conjunction with PPTP to create VPNs.
  • In conjunction with IPsec VPNs to allow passing of routing information between connected networks.
  • Distributed denial of service (DDoS) protected appliance to an unprotected endpoint.

So why would I even see GRE traffic from over a hundred IP addresses on HiNet’s network? This  is due to a large amount of comprised Internet of Things (IoT) devices on their network. The two most common types of these devices found were security (IP enabled) cameras and DVRs.

GRE traffic was found in late 2016 during a massive DDoS attack performed by the Mirai botnet.  I believe the traffic I’ve found is a leftover remnant of this botnet.  Similar conclusions have been reached by SANS Internet Storm Center users and heise Security.

HiNet

HiNet did not respond to my multiple requests for comment as to why they have chosen not to filter the rouge traffic from leaving their network.

Cisco noted the vulnerability of GRE decapsulation over ten years ago and how it could be used to bypass access-control lists (ACLs) .  Cisco also provided the steps to mitigate the issue, including how to block GRE traffic completely.

Are large scale GRE based DDoS attacks likely to return in the future? The answer is not certain, however Arbor Networks ASERT team noted in August 2016 that, “As with all types of DDoS attacks the miscreants stumble upon, we expect to see other botnets-for-hire and ‘booter/stresser’ services adding GRE to their repertoires in short order.”

Will the burden of filtering the rouge traffic fall to the ISP or the IoT device makers to prevent it from happening in the first place?

Quasi Networks responds as we witness the death of The Master Needler (80.82.65.66) for now

In a shocking development, The Master Needler – 80.82.65.66 has been taken offline. The death blow was as simple as notifying Quasi Networks upstream/transit providers, shown in the peer map below.

AS29073 - Quasi Networks

Once their upstream/transit providers was Cc’d on the email, the floodgates opened and the following response was received:

Hi,

We are a network operator with thousands of customers which are using services from many of our resellers.

Please dont expect we will reply at our abuse desk to each individual email, this is impossible. If you email us and dont get a response, this doesnt mean your case isnt handled.

all emails sent with CC messages to other addresses are threated as SPAM. Because you should ONLY email the correct abuse address and not waste other departments time.

You should only email our abuse address and not CC to operations and much more email addresses blabla.

So email abuse@quasinetworks.com in the future and remove all the bullshit and CC’s. It is also mentioned in the whois of the ip. Operations and gov.request are not mentioned for normal abuse.

noc CC operations @ gov.request @ etc etc. are all unnecessary. Because of all the CC’s your messages will end in our spambox in the abuse ticket system. Serious complaints are sent to the abuse address and nothing else. And they will be handled seriously.

This ip belongs to us, dont see what the ip broker (novogara) has to do with this.

And identify your organisation please in the future, in the meanwhile we will pass through your message to our abuse department.

QN Abuse.

This is turn triggered an actual human response from abuse@novogara.com:

Dear All,

Please remove us from this mailing-list, this is not a customer of ours. We received his request earlier at our support department and we called Charles at QN, they were already working on a fix with authorities and could not immediately filter the traffic.

Have a nice Friday.

However the RDP attacks continued so I sent another follow up and was told:

Our abuse team is still on this customer with authorities, it is part of a larger case.

please ban the ip temporary in your system

(till Thursday if possible). Thank you for understanding.

QN Abuse.

So I patiently waited until Thursday, June 15 and confirmed the attacks from 80.82.65.66 stopped at 3:42 PM local time.

Is this the last example of cybercriminal activity on Quasi Networks that we’ll see? History says, probably not.

Quasi Networks

Here is more information regarding Quasi Network’s troubled past courtesy of an article posted on Cisco’s blog last year:

Quasi Networks, actually used to be known as Ecatel [1][2][3].

Ecatel is a Dutch hosting provider founded in 2005, registered in the UK, and headquartered in The Hague. It offers offshore hosting options and, over the last decade, has consistently hosted criminal and toxic content [4][5], and generated spam and DDoS traffic from its IP space [6].

Ecatel is known to law enforcement, has been shut down by its peers at least once (in 2008) [7], and was subject in 2012 to DDoS attacks by Anonymous for hosting child porn [8].

In December of 2015, Ecatel changed their network name [9], and since then, AS29073 is officially called Quasi Networks [10][11]. More interestingly, Ecatel / Quasi Networks changed its registration from the Netherlands to the Seychelles, which is an offshore jurisdiction. This is a common evasive practice used by unscrupulous hosting providers that we’ve observed for several years.

In April of 2016, Ecatel rebranded yet again, and is now known as Novogara BV. In fact, Ecatel is still selling the same products on 4 different live websites: ecatel.net, ecatel.co.uk, ecatel.info and novogara.com.

 

Another day, another RDP attack, and an ISP that takes swift action

Recently I noticed numerous Remote Desktop Protocol (RDP) attacks originating from IP address 91.197.234.22. RDP attacks are nothing new, especially after a recent report of RDP Brute-Force Attacks Spreading Crysis Ransomware. However, an ISP that takes swift action against these type of attacks is not so common.

Remote Desktop Protocol

A WHOIS lookup for 91.197.234.22 on DomainTools.com notes the abuse contact as “noc@planet-telecom.eu” and provides the full contact information:

organisation:   ORG-PTL7-RIPE
org-name:       Planet Telecom Ltd.
org-type:       OTHER
address:        Sokolovska 395, 186 00 Praha 8, Prague, Czech Republic
e-mail:         noc@planet-telecom.eu
abuse-c:        PTN21-RIPE
mnt-ref:        MNT-PLANET-TELECOM
mnt-by:         MNT-PLANET-TELECOM
created:        2007-09-15T14:57:20Z
last-modified:  2016-03-23T09:42:12Z
source:         RIPE

I contacted noc@planet-telecom.eu about the incoming RDP attacks however did not receive any response. I tried to find alternative contact records on their website, http://planet-telecom.eu/.  To my dismay I found only a fake website that only leads to a WordPress Theme sales website: https://themeforest.net/item/total-responsive-multipurpose-wordpress-theme/6339019?ref=wpexplorer

Due to this, I escalated my request to the route maintainer (holder of the parent IP block) which is 3W Infra B.V. based in Amsterdam.  While I waited for their response, I also contacted their transit provider, Fusix Networks. I received a response from Niels Raijer, owner and chief architect at Fusix.

Neils stated:

We provide transit to Dedicolo/3W Infra and as such will not block the traffic, that would create a nasty precedent. As their transit provider we do use strict BCP38 filtering on their uplink in order to make spoofing impossible, however I understand well that the case you write about is amazingly enough not involving any spoofing.

Shortly thereafter, I received a response from 3W Infra’s CEO, Murat Bayhan:

As you might know and saw our press releases on the internet, due to rapid growth we are busy with huge migration that involves 4000 servers to move from shared dc hall to a private suite. Therefore all of our engineers are busy with this task including abuse department engineers – we do not have a lot of abuse therefore it is not really monitored daily.

My apologies for delay on your report.

We have informed our client for this and please let me know 72h later if you still experience this.

The attacks didn’t cease however and I followed up with Murat who contacted his reseller again.

Six hours later, I received another follow up from Murat:

We have null-routed the ip at our end.

This is a prime example where an ISP,  3W Infra, takes abuse complaints seriously and remediates the issue quickly.

Another day, another phishing scam, and an ISP that just doesn’t care

I eagerly opened my SPAM box in Gmail recently and discovered a standard-fare phishing attack email.  This particular one was impersonating USAA bank and claimed the user  needed to take action for a pending deposit.

USAA Phishing Email

Upon viewing the original source (raw copy) of the email, we can quickly identify where the phishing email came from.

Received: from 100-43-237-85.static-ip.telepacific.net ([100.43.237.85] helo=TS-PCMV.inland.local) by smtpout.telepacific.net with esmtp (Exim 4.69) (envelope-from <USAA.Customers@usmail.net>) id 1dFJlm-0001IH-SU; Mon, 29 May 2017 05:27:38 -0700

According to DomainTools, the IP 100.43.237.85  has been assigned to Telepacific Communication, currently known as TPx Communications  as of April 11, 2017 and is headquartered in Los Angeles, CA. The WHOIS record further details the customer operating the IP address as “INLAND RHEUMATOLOGY & OSTEOPUROSIS MED GROUP”

So how did this email get through in the first place?  Interestingly, further details are found in the original source of the email:

X-Spam-Beval: 53
X-Spam-Score: 5.3
X-Spam-Report: Spam detection software, running on the telepacific email platform has scanned this email in an attempt to identify spam. The original message has been attached to this so you can view it or label similar future email.
If you have any questions, please see http://www.telepacific.com/contact/customerService/ Content analysis details:
(5.3 points, 2.0 required) pts rule name
description —- ———————- ————————————————– 0.0 URIBL_BLOCKED
ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: usaa.com] 0.0 TVD_RCVD_IP
Message was received from an IP address 1.5 TVD_PH_SEC
BODY: Message includes a phrase commonly used in phishing mails 0.0 HTML_MESSAGE
BODY: HTML included in message 0.1 MISSING_MID
Missing Message-Id: header 0.0 LOTS_OF_MONEY
Huge… sums of money 0.6 TO_EQ_FM_DIRECT_MX
To == From and direct-to-MX 3.0 URI_WP_HACKED
URI for compromised WordPress site, possible malware -0.0 AWL
AWL: Adjusted score from AWL reputation of From: address

So it appears the email was scanned by Telepacific Communication’s anti-spam software but was allowed to slip through. I reported the issue to abuse@telepacific.com and received a bounceback:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:

abuse@telepacific.com

host a2nlsmtpcp-v01.shr.prod.iad2.secureserver.net [198.71.232.0]

SMTP error from remote mail server after end of data:

552 5.2.0 FP6Vd4FrlCQzG :: CPANEL :: Message rejected for spam or virus content ::

Please include this entire message when contacting support ::

The irony of this is quite laughable since the original message was not flagged as malicious but the act of reporting it was.  I sent a follow up message to Telepacific Communication’s abuse department but did not receive any response.

A conversation with RIPE NCC regarding Quasi Networks LTD (AS29073)

Recently I contacted RIPE NCC regarding Quasi Networks (AS29073) and their blatant disregard to abuse complaints. I have contacted Quasi Networks via the email addresses documented in the RIPE WHOIS database:

abuse@quasinetworks.com
operations@quasinetworks.com
gov.request@quasinetworks.com

However to little surprise, I received no response or confirmation of my emails. The attacks from IP addresses managed by Quasi Networks continue at this very moment.

I also tried contacting the building they were located in, per the RIPE database WHOIS record:

Suite 1, Second Floor
Sound & Vision House, Francis Rachel Street
Victoria, Mahe, SEYCHELLES

However no one at Sound & Vision Pty Ltd. answered the phone or returned my email.

So it appears Quasi Networks has not received my messages due to invalid emails addresses provided or has chosen to ignore to them, both a violation of RIPE NCC policies.

RIPE NCC

I contacted the RIPE NCC Regulatory Review Team about this issue and spoke with Laurens Hoogendoorn, RIPE NCC IP resource analyst and discussed the following questions:

Me: Why does RIPE NCC require the burden of proof to fall to the victim of network abuse when the RIPE Database contains invalid or false information for an organization?

Laurens: At the moment that they become a member they sign an agreement  in which they confirm that they will keep the contact details up-to-date. We consider contact details valid until proven otherwise and this is why we ask to provide evidence that contact details are invalid.

Me: Why does RIPE NCC not assist in the facilitation of communication between users and organizations in the RIPE Database when no response is received from the organization?

Laurens: As a membership association we implement and enforce policies that are made by the RIPE Community. We do have the mandate from the RIPE community to take action if contact details are proven to be invalid. We don’t have the mandate from the community to liaise between a party that reports abuse and the resource holder that is unresponsive.

Me:  Does RIPE NCC recommend contacting law enforcement in the  organization’s jurisdiction to assist in such matters mentioned above?

Laurens: We always recommend to contact the relevant authorities
if you are the victim of a crime.

Laurens also recommended contacting the holder of the parent IP block, Novogara LTD via email (only available method) at support@novogara.com. This is did not see to follow the documented protocol, so I asked additional follow up questions:

Me: You stated, “Finally, I do want to emphasise that I did double check our records before I sent my first email and we don’t have any reason to believe at this moment that the contact details are invalid.” What steps did you (RIPE NCC) take to complete this check? Did you contact the organization (Quasi Networks LTD) in any way to verify? Does RIPE NCC maintain a “backchannel” to organizations? You recommended that I “could also try to contact the holder of the parent IP block; maybe they are able to assist further.” I was not aware of this as the standard communication protocol per RIPE NCC policies regarding unresponsive abuse complaints to organizations. Is this something you recommended to try informally?

Laurens: 80.82.65.0/24 is a PA assignment and was created by our member Novogara LTD without the involvement of the RIPE NCC. For PA assignments you can indeed contact the holder of the parent block (as it is their address space). Quasi Networks LTD also holds AS29073 and the RIPE NCC did validate the registration details at the moment that they received the ASN.

So how does RIPE NCC policies differ from other Regional Internet Registries? In the case of invalid WHOIS details, there are indeed some differences.  The American Registry for Internet Numbers  (ARIN) will take action to contact organizations when they receive a report of invalid WHOIS data. Per Jonathan Roberts, ARIN Registration Services, ARIN will attempt to find updated contact information for invalid abuse records.

In my case, the attacks from Quasi Networks will continue unabated with no regulatory power from RIPE NCC to stop them. I have contacted support@novogara.com for assistance but have not received a response.

 

Intel® AMT related port attacks on the rise and hits close to home

It comes at no surprise attacks on ports related to Intel® AMT have risen after the recent disclosure of an escalation of privilege vulnerability in Intel® Active Management Technology (AMT) that can allow an unprivileged attacker to gain control of the manageability interface of the affected servers. This exploit has been dubbed “Silent Bob is Silent” and is shocking in its simplicity to perform.  Intel has published a full mitigation guide to disable the attack vector until a permanent solution is in place.

Per Intel® documentation, the affected ports to monitor are 16992, 16993, 16994, 16995, 623, and 664. So, let’s review the recently dropped packets on those ports and where they’re coming from since the vulnerability was disclosed:

Intel AMT ports attacked

The good news is that it appears a majority of the dropped packets where from scanning services, such as the Shadowserver Foundation and Project Sonar. However the remaining attackers probably didn’t have good intentions in their attempt to get in

The bad news is after running the INTEL-SA-00075 Discovery Tool, I found one of my servers was affected.

Intel AMT vulnerability detected!

I contacted the manufacturer of the motherboard, Super Micro Computer, Inc., and spoke with Application Engineer Kin Yan.  He stated, “Our team is working on this BIOS update to fix this issue. The target release date of this BIOS is by the end of this month.” In the meantime he strongly recommended to disable Intel® AMT in the BIOS settings until the vulnerability was patched.

Latest firmware update for Amcrest cameras results in constant connection to cloud servers even for non-cloud customers

I recently updated the firmware of my Amcrest IP2M-841 and  IP3M-943 cameras to the latest version. Afterward I began noticing a constant connection to three separate, unknown servers.

Amcrest likes to watch you.

I found this odd as I had not seen these connections prior to the firmware update.  Performing a simple DNS lookup for each yielded the following:

ec2-52-90-88-253.compute-1.amazonaws.com
ec2-107-23-233-106.compute-1.amazonaws.com
ec2-52-91-65-92.compute-1.amazonaws.com

This clearly shows that all three servers are hosted on Amazon AWS.  Unfortunately this tells  us nothing about who is using Amazon’s infrastructure to talk to my cameras. So to investigate further, I went directly to ec2-52-90-88-253.compute-1.amazonaws.com in the browser, noting to use HTTPS since port 443 was being used.

Dan Burkett also likes to watch!

This triggered a warning that the SSL certificate was not trusted and could not connect.  The error message provided by Chrome was “ERR_BAD_SSL_CLIENT_AUTH_CERT” with no further details.  I was not able to find out the certificate was self-signed by someone named “Dan Burkett” until I used Pale Moon.  So who is Dan Burkett and why are my cameras using a self-signed SSL cert to speak to him?

According to CrunchBase, Dan Burkett is co-founder and CTO at Camcloud, based in Ontario, Canada, where he primarily focuses on platform architecture, mobile development and streaming media.

So is Dan watching me undress?  Probably not, but let’s see how much bandwidth (traffic) my IP2M-841 camera is using to talk to Dan’s servers.  This is accomplished with an SNMP sensor in PRTG once the SNMP option is enabled and the strings set in the camera configuration page.

Camera bandwidth (traffic) usage

Over the last two days the traffic has been constant, averaging about 14 kbit/s during the time period.  Is this enough usage to be watching a secret live video feed of me? Not likely as that equates to a transfer rate of 1.75 kilobytes per second.  At this level even a low resolution JPEG snapshot being taken at a reasonable interval would be near impossible.

So what is actually being disseminated to these mysterious cloud servers? The only way to find out would be to complete a packet capture with Wireshark and monitor the traffic in realtime.

Wireshark Capture

Unfortunately the traffic to the mysterious cloud servers is encrypted, so without the server’s private key we will never known what is being transmitted.

However, we are able to find out the DNS names of the servers based on the queries sent from the camera.  Finally the names were revealed when the DNS lookup answers came in:

Queries
ftps.hostedcloudvideo.com: type A, class IN
Answers
ftps.hostedcloudvideo.com: type A, class IN, addr 54.159.91.18
ftps.hostedcloudvideo.com: type A, class IN, addr 54.224.213.162
ftps.hostedcloudvideo.com: type A, class IN, addr 54.80.240.204
ftps.hostedcloudvideo.com: type A, class IN, addr 54.80.249.22
ftps.hostedcloudvideo.com: type A, class IN, addr 54.158.231.89
ftps.hostedcloudvideo.com: type A, class IN, addr 23.20.159.229
ftps.hostedcloudvideo.com: type A, class IN, addr 54.159.95.70
ftps.hostedcloudvideo.com: type A, class IN, addr 54.166.187.129
ftps.hostedcloudvideo.com: type A, class IN, addr 54.162.101.239
ftps.hostedcloudvideo.com: type A, class IN, addr 54.198.155.118
ftps.hostedcloudvideo.com: type A, class IN, addr 54.158.208.74
ftps.hostedcloudvideo.com: type A, class IN, addr 54.146.1.185
ftps.hostedcloudvideo.com: type A, class IN, addr 54.167.219.193
ftps.hostedcloudvideo.com: type A, class IN, addr 54.162.218.154
ftps.hostedcloudvideo.com: type A, class IN, addr 54.146.46.97
ftps.hostedcloudvideo.com: type A, class IN, addr 54.221.201.14
ftps.hostedcloudvideo.com: type A, class IN, addr 23.20.254.144

Queries
config.amcrestcloud.com: type A, class IN
Name: config.amcrestcloud.com
Answers
config.amcrestcloud.com: type A, class IN, addr 54.158.250.32

Queries
command-4.amcrestcloud.com: type A, class IN
Answers
command-4.amcrestcloud.com: type A, class IN, addr 52.90.88.253

Queries
media-amc-0.hostedcloudvideo.com: type A, class IN
Answers
media-amc-0.hostedcloudvideo.com: type A, class IN, addr 54.162.224.230

Queries
dh.amcrestsecurity.com: type A, class IN
Answers
dh.amcrestsecurity.com: type A, class IN, addr 54.84.228.44

This shows the constant connection to 52.90.88.253 is the “command server” command-4.amcrestcloud.com.  Amcrest Support was not able to provide any reasons why is this connection necessary.

 

Bonus Notes

The last DNS query shows another connection the camera made to another server, dh.amcrestsecurity.com. This connection was not encrypted.

Wireshark Capture 2

It appears the camera reads the file http://dh.amcrestsecurity.com/readbinfile.html as some sort of firmware check.

 

6/1/2017 — Update

After much discussion with Amcrest Support regarding this issue, the following update was received:

Hello Troy,

I’m from Amcrest Cloud support. Sorry for all the back and forth. We’ve finally come to understand the situation. Thanks for all the feedback via email and your blog post (great analysis btw). A couple of points:

1 – All the traffic from camera -> cloud is expected and standard for this kind of device and matches what would be in our server logs, including pings to the cloud servers, certificate exchange/setup, etc.

2 – The problem you’ve identified is that the outbound communication is supposed to stop after 2 hours if a user has not attached their camera to a cloud account. We have finally reproduced this problem internally and you’re right, there is an issue in the firmware.

We are working with the firmware team to ensure this traffic is halted after 2 hours, as intended. I’m currently testing a release that fixes this, so it shouldn’t be long before the new firmware is released.

Once again, thanks for taking the time to dig into our product at this level of detail.

Regards,
Alen

8/22/2017 — Update

Amcrest has fixed this issue for certain cameras / firmware versions. Read more in my update here.

Another look into no-reverse-dns-configured.com’s troubled past

I previously reported on no-reverse-dns-configured.com and the current and previous owners.  But what about the February 2016 botnet attacks? Who was the owner when the domain name was invoked in those attacks?

According to DomainTools, the owner of no-reverse-dns-configured.com in February 2016 was Slawek Modrzejewski.  Slawek was original owner of the domain name since it was first registered in 11/15/2015.

On 4/9/2016, the registration for no-reverse-dns-configured.com was dropped by GoDaddy.  Five days later, the registration was picked up by SouthNames Inc. (NamePal.com) with an anonymous owner protected by United Privacy Corp, which is based in Belize.

In addition to the number WHOIS record updates for no-reverse-dns-configured.com, there has been an equally historic hosting history.  As of this writing, no-reverse-dns-configured.com has been pointed to 14 different IP addresses, shown in the illustration below from DomainTools.

Epic hosting history!

During the botnet attacks, the hosting IP address was changed to 23.250.123.223 which is managed by ColoCrossing.  After the attacks the server IP address was changed to 12.12.12.12 – which is a bit odd as that IP is managed by Alascom, Inc. in Anchorage, Alaska.  Further information provided by DomainTools shows 78 domain names have A records going to 12.12.12.12.

This leads to none of those domain names actually resolving anywhere, which may appear to be some sort of “spammer nullroute”.  The full list of the 78 domain names pointing to 12.12.12.12 is available here. I notified AT&T/Alascom about these fake A records pointing to their infastructure and will follow up if I hear back from their NOC/IPAM team.