- anti-abuse-wg - mailman.ripe.net

[Misc] Research project on blacklists
by Anushah Hossain 18 Jul '19

18 Jul '19

Hi everyone, I'm a researcher at UC Berkeley and the International Computer Science Institute. My colleagues and I are working on evaluating and improving the accuracy of blacklists. As part of this work, we'd like to hear from you about the blacklists you currently use, what you perceive as their strengths and weaknesses, and any thoughts you have on how they might be improved. We've prepared an anonymous survey where you can share your views: https://berkeley.qualtrics.com/jfe/form/SV_200mg5hnQiAOgUl If you have five to ten minutes free today to fill it out, I would greatly appreciate your help! Thank you, and please don't hesitate to respond to me with comments or questions. (Apologies if you receive this message twice - trying to minimize cross-posting while still reaching a broad audience) Best, Anushah -- Anushah Hossain, PhD Student Energy and Resources Group, UC Berkeley

3 2

Privacy Ukraine LLC
by zedsdead＠cock.li 15 Jul '19

15 Jul '19

RIPE member Known Holdings Ltd operated by Krunoslav Begic set-up a fake entity called "Privacy Ukraine LLC" (AS206106) to host criminal enterprises. org-name: Privacy Ukraine LLC org-type: OTHER address: Mykhaila Kotsyubynskoho St, 4b address: Kiev 01030 There is no "Privacy Ukraine LLC" on this address, and there is no phone number, nor working email account either. We believe that this entity was setup in order to reduce the amount of abuse complaints coming to Mr. Begic's main account. There are only illegal websites on all of the /24's totaling 1,024 addresses. He assigned an entire /24 to one of the most notorious piracy websites operated out of Sweden by Antoine Hedgecock a/k/a macnibblet of Interactive Solutions and Roave: https://bgp.he.net/net/185.192.125.0/24#_dns Google's Transparency Report: https://transparencyreport.google.com/copyright/domains/camgirlvideos.org This domain had 929,954 URLs over 25,121 individual requests requested for delisting from our Search results. https://transparencyreport.google.com/copyright/domains/camgirl.gallery This domain had 3,551,534 URLs over 34,726 individual requests requested for delisting from our Search results.

2 1

Update on Impact Analysis for 2019-03, “BGP Hijacking is a RIPE Policy Violation”
by Marco Schmidt 12 Jul '19

12 Jul '19

Dear colleagues, We would like to give you an update on our impact analysis for the policy proposal 2019-03, “BGP Hijacking is a RIPE Policy Violation”. After feedback from the initial Discussion Phase, the proposers have created a second version of the proposal that will move forward to the Review Phase. As per the Policy Development Process (PDP), the RIPE NCC must perform an impact analysis on the proposal and publish this before the Review Phase can begin. We usually aim to finish our analysis within four weeks. In this case, our review has taken much longer than normal. This is because the proposal creates a completely new process within the RIPE NCC, with a number of operational, legal and communications implications. The proposal also outlines detailed steps for this process that have to be checked for consistency and feasibility. We are almost finished and expect this to be ready soon. The WG Chairs will then work with the proposers to determine when the new version of the policy should be published (along with our impact analysis) so that the Review Phase can start. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 1

New on RIPE Labs: Report from the workshop on Coordinating Attack Response at Internet Scale (CARIS2)
by Mirjam Kuehne 27 Jun '19

27 Jun '19

Dear colleagues, The second Coordinating Attack Response at Internet Scale workshop (CARIS2) met earlier this year to discuss changes to infrastructure and monitoring as on-the-wire or transport encryption becomes stronger (for example, TLS 1.3 and QUIC) and ubiquitous. Please find the report by Kathleen Moriarty on RIPE Labs: https://labs.ripe.net/Members/kathleen_moriarty/thinking-on-the-edge-key-to… Kind regards, Mirjam Kühne RIPE NCC

1 0

Microsoft New Abuse Policies
by ac 02 Jun '19

02 Jun '19

Hi All, Today it is me, tomorrow it may be you? Microsoft has new abuse policies in terms of email abuse and it is interesting insofar as it is mysterious Which is perfectly fine, it is Microsoft's infrastructure and they may do and decide whatever they want - But - it is important to understand ABUSE in all it's forms. I am saying that this Microsoft behavior is Abuse in itself as they leveraged their monolopy in operating systems into an eventual email dominance and their behavior is abuse. Anyway, you will recall that I posted here about the AI at Microsoft, as I (a human) took 20 minutes to complete their web form (and solve their stupid capcha) and the Microsoft response was so very quickly: "no" Well, I escalated and escalated the "no we are not going to accept relay from you, internationally from any @microsoft infrastructure" for an IP number and sender domains that are 100% clean and has, in ten years, not even has a single abuse complaint from anywhere: http://multirbl.valli.org/lookup/5.9.29.165.html I received the final Microsoft response this morning after many email exchanges, and with different "people": +++++++++++++++++++++++++++++++++ Hello, As previously stated, your IP do not qualify for mitigation at this time. I do apologize, but I am unable to provide any details about this situation since we do not have the liberty to discuss the nature of the block. At this point, I would suggest that you review and comply with Outlook.com's technical standards. This information can be found at https://postmaster.live.com/pm/postmaster.aspx <https://postmaster.live.com/pm/postmaster.aspx> We regret that we are unable to provide any additional information or assistance at this time. Best regards, Outlook.com Deliverability Support +++++++++++++++++++++++++++++++++++++++ The staff are "not at liberty" i.e FREE and "at this point" They are not referring me to RFC as my emails comply with RFC, IETF and all standards, so there is no 'technical' reason... or to any abuse by myself (as that does not exist) instead I am being directed to copious amounts of "policy" where I have to work through pages of drivel with an end result of them still saying "no" and with a result of wasting my time. Of course, as I already said: Microsoft can refuse to accept email from anyone they choose and for any reason they choose. So, there is nothing that I can do or say and it is what it is. Andre

1 0

Re: [anti-abuse-wg] Interesting email abuse header extract
by Suresh Ramasubramanian 02 Jun '19

02 Jun '19

I won't deny that header forgery is still common. I'm just saying that there's zero indication of whether or not a particular header is forged by just looking at it in isolation. On 01/06/19, 2:42 PM, "anti-abuse-wg on behalf of ac" <anti-abuse-wg-bounces(a)ripe.net on behalf of ac(a)main.me> wrote: Hi, It is not a forgery and the extract is the second line Received: (which I am not able to post in public :) ) anyway it is allowed relay by 37.212.178.8 (for whatever reason, is not relevant) what is relevant is the addition of [ ] to the helo on a 2nd Received: the first Received: is "supposedly" the actual sender (and from my data, the first Received: is fake/compromised/etc) so, i guess what I am saying is look at the brackets and take my word for the rest :) either way, whether you accept my word or not, the manipulation of headers, in itself, with the goal of attacking 3rd parties (or "framing" 3rd parties) is still a very evil form of internet abuse that is not really discussed or talked about much? Andre On Sat, 01 Jun 2019 14:27:13 +0530 Suresh Ramasubramanian <ops.lists(a)gmail.com> wrote: > Without looking at the other received headers there's no way to say > that this is header forgery. > > Many mail clients will HELO as whatever IP they're provisioned on, > and both IPs belong to a provider in Belarus. > > So unless this header was inserted in a way that there's no > continuity with the other headers, I can't see any specific sign of > forgery here. > > Carrier Grade NAT maybe so that the IP your mailserver sees vs the IP > stamped in the HELO string will differ. > > --srs > > On 01/06/19, 2:06 PM, "anti-abuse-wg on behalf of ac" > <anti-abuse-wg-bounces(a)ripe.net on behalf of ac(a)main.me> wrote: > > Hello, > > The purpose of the abuse header extract in this thread is obvious > but still interesting. I started thinking about all the interesting > ways that cyber criminals, nation states, large corporates and other > abuse purveyors and distributors are always constantly trying to find > ways to break abuse reporting systems, RBLs DNSBL's Reputational and > other services. > > Here is the interesting extract : > Received: from mm-8-178-212-37.vitebsk.dynamic.pppoe.byfly.by > ([37.212.178.8]:51058 helo=[178.121.247.67]) > > It is only interesting because it is so old that it is unusual to > see such an old method in use in 2019. Maybe it is a "new" nation > state trying to build or expand it's cyber weapon arsenal, maybe it > is R&D on a wannabe corporate spammer or corporate spam enabler (esp) > maybe it is just a young cyber criminal > > Either way, imho, this type of abuse is even worse than other > types of abuse. As with everything, I guess it is also perspective. > From a nation state perspective it is national security, from a cyber > crime perspective it is r&d, from an abuse admin perspective it is > extreme evil and from the average joe soap or john doe (or whatever > the politically correct method of referring to the average person is) > - the average person simply does not care :) > > Andre > > > >

2 1

Re: [anti-abuse-wg] Interesting email abuse header extract
by Suresh Ramasubramanian 01 Jun '19

01 Jun '19

Without looking at the other received headers there's no way to say that this is header forgery. Many mail clients will HELO as whatever IP they're provisioned on, and both IPs belong to a provider in Belarus. So unless this header was inserted in a way that there's no continuity with the other headers, I can't see any specific sign of forgery here. Carrier Grade NAT maybe so that the IP your mailserver sees vs the IP stamped in the HELO string will differ. --srs On 01/06/19, 2:06 PM, "anti-abuse-wg on behalf of ac" <anti-abuse-wg-bounces(a)ripe.net on behalf of ac(a)main.me> wrote: Hello, The purpose of the abuse header extract in this thread is obvious but still interesting. I started thinking about all the interesting ways that cyber criminals, nation states, large corporates and other abuse purveyors and distributors are always constantly trying to find ways to break abuse reporting systems, RBLs DNSBL's Reputational and other services. Here is the interesting extract : Received: from mm-8-178-212-37.vitebsk.dynamic.pppoe.byfly.by ([37.212.178.8]:51058 helo=[178.121.247.67]) It is only interesting because it is so old that it is unusual to see such an old method in use in 2019. Maybe it is a "new" nation state trying to build or expand it's cyber weapon arsenal, maybe it is R&D on a wannabe corporate spammer or corporate spam enabler (esp) maybe it is just a young cyber criminal Either way, imho, this type of abuse is even worse than other types of abuse. As with everything, I guess it is also perspective. From a nation state perspective it is national security, from a cyber crime perspective it is r&d, from an abuse admin perspective it is extreme evil and from the average joe soap or john doe (or whatever the politically correct method of referring to the average person is) - the average person simply does not care :) Andre

2 1

Interesting email abuse header extract
by ac 01 Jun '19

01 Jun '19

Hello, The purpose of the abuse header extract in this thread is obvious but still interesting. I started thinking about all the interesting ways that cyber criminals, nation states, large corporates and other abuse purveyors and distributors are always constantly trying to find ways to break abuse reporting systems, RBLs DNSBL's Reputational and other services. Here is the interesting extract : Received: from mm-8-178-212-37.vitebsk.dynamic.pppoe.byfly.by ([37.212.178.8]:51058 helo=[178.121.247.67]) It is only interesting because it is so old that it is unusual to see such an old method in use in 2019. Maybe it is a "new" nation state trying to build or expand it's cyber weapon arsenal, maybe it is R&D on a wannabe corporate spammer or corporate spam enabler (esp) maybe it is just a young cyber criminal Either way, imho, this type of abuse is even worse than other types of abuse. As with everything, I guess it is also perspective. From a nation state perspective it is national security, from a cyber crime perspective it is r&d, from an abuse admin perspective it is extreme evil and from the average joe soap or john doe (or whatever the politically correct method of referring to the average person is) - the average person simply does not care :) Andre

1 0

2019-04 New Policy Proposal (Validation of "abuse-mailbox")
by Marco Schmidt 01 Jun '19

01 Jun '19

Dear colleagues, A new RIPE Policy proposal, 2019-04, "Validation of "abuse-mailbox"", is now available for discussion. This proposal aims to have the RIPE NCC validate "abuse-c:" information more often, and introduces a new validation process that requires manual input from resource holders. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-04 As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the Anti-Abuse Working Group Chairs, decides how to proceed with the proposal. We encourage you to review this proposal and send your comments to <anti-abuse-wg(a)ripe.net> before 14 June 2019. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

26 82

Re: [anti-abuse-wg] AI used for spam and abuse at Microsoft?
by Ángel González Berdasco 30 May '19

30 May '19

They have many minions working there, Andre. And it's not a work they require much study.(they probably input that into a tool that says Yes/No). If it wasn't blocked for your own mail, it may be due to mails sent from its neighbourhood. Reply to their ticket and insist. Cheers

2 1