[anti-abuse-wg] Ecatel Network (Quasi Networks)

I wrote one of the articles about Quasi Networks you mentioned.  You can
see how "professional" they are in my most recent encounter with them:
https://badpackets.net/quasi-networks-responds-as-we-witness-the-death-of-the-master-needler-80-82-65-66-for-now/




__

*Troy Mursch*

*Information Security Analyst*

Bad Packets Report <https://badpackets.net/>

troy at wolvtech.com

(702) 509-1248

On Fri, Jul 21, 2017 at 2:58 AM, Sergey <gforgx at fotontel.ru> wrote:

> Hi,
>
> It seems to be a really long story and it's strange they're not listed for
> instance in Spamhaus DROP.
>
> I think this can only be resolved by RIPE NCC because both of its
> upstreams (AS3216 and AS12714) are huge Russian transit ISPs which would
> most likely be reluctant or maybe even resistant to abuse reports.
>
>
> I'm not saying it's not up to RIPE NCC at all (it is) but I think it
> should be first addressed to their upstreams which according to BGP table
> are: AS3216 and AS12714, and also they're seen on AMS-IX. But I don't
> actually feel like Beeline and NetByNet (huge Russian transit ISPs) will do
> anything on this.
>
> On 07/21/17 12:09, phishing at storey.xxx wrote:
>
> hello,
>
> I have been referred to this mailing list by the Reg Review account.
>
> I am writing about the current situation with "Quasi Networks", AS29073 .
>
> This AS is run by a criminal front:
>
> https://justinpineda.com/2011/04/30/understanding-ecatel/
>
> *"The Ecatel Network is part of the Russian Business Network (RBN) which
> is known for cybercrime activities since 2007."*
>
> It is completely unaccountable and has been engaging in endless cyber
> crime activities for a number of years:
>
> https://www.infosecurity-magazine.com/news/us-russia-
> are-top-cyber-threat-hosts/
>
> *"In the first quarter of 2013, the worst host overall was found to be
> Ecatel Network in the Netherlands, which, while hosting only 13,000 IPs,
> still manages to host more than it's fair share of malicious content. “This
> quarter we see the return of Dutch hosting provider Ecatel to the No. 1
> rank, having held the position at various times in the past,” Host Exploit
> said. “Ecatel does not top the rankings for any particular category of
> activity, but rather for a consistently poor showing across the board.”
> Botnets in particular seem to like the Dutch provider."*
>
> Persistant emails to them are ignored:
>
> https://badpackets.net/a-conversation-with-ripe-ncc-
> regarding-quasi-networks-ltd/
>
>
> and due to the absence of an accountability mechanism in RIPE policy, they
> continue:
>
> https://www.lowendtalk.com/discussion/70172/ecatel-ltd-
> quasi-networks-ltd-ibc
>
> https://blogs.cisco.com/security/massive-increase-in-
> reconnaissance-activity-precursor-to-attack
>
> http://www.webhostingtalk.com/showthread.php?t=1182576
>
> https://justinpineda.com/2011/04/30/understanding-ecatel/
>
> Can you introduce a mechanism that ensures that rogue operators like this
> network are disassembled.
>
> The current situation is ridiculous! Although I understand there are costs
> associated with monitoring such complaints, the current situation cannot
> continue for ever.
>
> Also, the address used by the AS is a bogus "Seychelles" address and they
> obviously do not operate out of Seychelles.
>
> I have suggested to Reg Review that manual dispatching of a paper letter
> based code to the nominated address be necessary to activate assigned IP
> addresses ("Two factor authentication").
>
> They indicate that this would create to much of a burden on your
> organisation, but the current situation of rogue criminals using false
> addresses and then RIPE relying on random people to notify RIPE (and then
> ignore their request!) needs to be addressed.
>
> -----
>
>
> --
> Kind regards,
> CTO at
> *Foton Telecom CJSC*
> Tel.: +7 (499) 679-99-99 <+7%20499%20679-99-99>
> AS42861 on PeeringDB <http://as42861.peeringdb.com/>, Qrator
> <https://radar.qrator.net/as42861>, BGP.HE.NET <http://bgp.he.net/AS42861>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20170721/25978615/attachment.html>