Re: [mailop] Microsoft lays hands on login data: Beware of the new Outlook
On 11/10/23 16:54, Carsten Schiefner via mailop wrote: sort of triggered by Benoit's recent and absolutely spot-hitting rant about Microsoft's inability resp. unwillingness to appropriately deal with spam complaints, I thought I should share this article: Microsoft lays hands on login data: Beware of the new Outlook https://www.heise.de/news/Microsoft-lays-hands-on-login-data-Beware-of-the-new-Outlook-9358925.html I think we have noticed that at least in February (due to accounts blocked as they were considered to be compromised). Last April, I have sent an email about this subject to two "contacts" I have at Microsoft but I had no answer. Although it is not strictly related to email service providers' operations, I wonder about the unintended resp. unwanted side effects wrt. email operations it could have that you have to involuntarily hand off your credentials to a third party. What we have seen here is Microsoft IPs connecting to mailboxes using IMAP. These connections seemed to be uncorrelated from real users connections (graphs looked mostly flat) and Microsoft did not really care about credentials validity. At one point, one of their IPs was flagged as fraudulent (?) and we started to block accounts. This started a snowball effect (authentications on blocked accounts were failing, so reputation of their IPs was decreasing and more accounts were blocked). François ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] How to address Microsoft if spaming Office365 customers cause collateral damage for other Office365 customers sharing the same IP?
On 3/30/23 18:36, Hans-Martin Mosner via mailop wrote: I try to tackle this by analyzing domains present in mail headers and rejecting mails accordingly. As you've experienced, talking the Office365 customers into leaving their crappy host isn't working, so I will have to accept that a significant part of the traffic from O365 sources is legit, and blocking their IPs is not an option. I'm not asking for these people to leave Office365, I just wish Micrsoft would not take months to remove domains that were created just to send spams. One of my issue here is french laws are requiring us to stay neutral. There is something equivalent in Europe regulations : « REGULATION (EU) 2015/2120 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL » of 25 November 2015 Article 3 - Safeguarding of open internet access [...] Providers of internet access services shall not engage in traffic management measures going beyond those set out in the second subparagraph, and in particular shall not block, slow down, alter, restrict, interfere with, degrade or discriminate between specific content, applications or services, or specific categories thereof, except as necessary, and only for as long as necessary, in order to: (a) comply with Union legislative acts, or national legislation that complies with Union law, to which the provider of internet access services is subject, or with measures that comply with Union law giving effect to such Union legislative acts or national legislation, including with orders by courts or public authorities vested with relevant powers; (b) preserve the integrity and security of the network, of services provided via that network, and of the terminal equipment of end-users; (c) prevent impending network congestion and mitigate the effects of exceptional or temporary network congestion, provided that equivalent categories of traffic are treated equally. From what I understand, if I set rules on my reputation system to block servers whose traffic is abnormal, these rules must be applied to all those matching servers, not just to most of them but the biggest ones. François ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is there any analysis on root causes of mail account break-ins?
On 11/17/21 9:12 PM, Jarland Donnell via mailop wrote: > If you can get the passwords that are going around in these database dumps and > compare them to email accounts in your system, test those passwords against > their email accounts using automation, and then force a password change it if > matches, I have been there, done that and got plenty of passwords changed by the attackers... But if you really want to go an extra mile, with such a list, what you may do is blocking your users from re-using their compromised passwords even with small transformations. I am using the Levenshtein algorithm (slightly modified) and allow new passwords only if the distance from any compromised password is "sufficient". > you are not only going to stop a ton of compromises you're probably > going to get a raise. It didn't work... François ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is there any analysis on root causes of mail account break-ins?
On 11/17/21 9:10 AM, Hans-Martin Mosner via mailop wrote: > Here I want to focus on hacked mail accounts. I can think of two major root > causes but I have no idea about their relative significance: > * Easily guessable passwords, with two subcauses for exploits: > o Brute force authentication attempts - I'm seeing them regularly, Are you sure it is really *full brute* force attemps and not a *password reuse* attack ? Some of my users have dozens of passwords compromised and an attacker have plenty of information about : 1/ what are the usual password used for an email 2/ what kind of transformations are applied by its user. so that attackers might dramatically limit the volume of trials needed for that kind of attack. Just an example, one of my users have that kind of compromised passwords in "public" lists (some letters have been changed and this account has been disabled for a few years) : - Yt6j8mxx - 123ytm - ytjm0 - Yt6j8M - Yt7j6M - yyt6j8M - yt6j8mm - 123yt6j8m - yt6j8mz - yt6j8mq - yt6j8ma - yt6j8m9 - yt6j8m8 - yt6j8m777 - yt6j8m7 - yt6j8m6 [...] As an attacker, I would try to 1/check each of these passwords 2/ find the most common roots of these passwords and brute force only using usual transformations (in this example, there are case transformations, adding "123" at the beginning, adding a single character at the end, adding several time the same character at the end). I usually see "slow and low" attacks (one password checked per account, per IP and per day) and real brute force attacks are quite uncommon on the mail servers I manage. > and the most egregious networks (e.g. > 5.188.206.0/24) are fully blocked at our mailserver, but some mailops > are > less struct about blocking such abusers. IMHO, the main issue is not really about blocking abusers but being able to identify compromised accounts. > * Malware on client machines where passwords are either stored in a password > vault, or entered manually. You are missing pĥishing attacks and probably compromised servers. > My gut feeling is that some organizations are especially prone to hacked mail > accounts. We're seeing lots of south american government agency users, and > many > accounts at educational institutions. I am afraid the issue is broader than that. Yes, there are many issues with educational institutions (I have seen that kind of cases from all over the world) but I also have seen compromised accounts used to spam from small enterprises (real estates, plumbers, architects, etc.) > The latter are often hosted using Microsoft O365 services, I would say O365 is probably a catalyst and probably not the cause. What you sees usually are the spams. This means the spammer was able to know how to identify compromised accounts *and* he was able to know how to send mails. With any domain using O365, spammers already have all the needed information. The (french banks) phishings I used to receive only from O365 are now also sent directly from servers hosted at universities. I even have received a scam sent from a compromised account at a french ministry. > and I highly suspect that weak passwords for all the > freshly created student accounts may be a major cause, although exfiltrated > password data may be a possibility, too. Brute force on weak passwords seems to be unlikely to me as long as you are using network services. I would think the main issue is passwords reuses. François ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail out of office replies
On 9/11/20 2:07 PM, Kieran Cooper via mailop wrote: > Does anyone have any knowledge of how Gmail decides when to send an > auto-reply? RFC 3834 : 2. When (not) to send automatic responses An automatic responder MUST NOT blindly send a response for every message received. In practice there are always reasons to refuse to respond to some kinds of received messages, e.g., for loop prevention, to avoid responding to "spam" or viruses, to avoid being used as a means to launder or amplify abusive messages, to avoid inappropriately revealing personal information about the recipient (e.g., to avoid an automatic indication that a recipient has not read his mail recently), and to thwart denial-of-service attacks against the responder. The criteria for deciding whether to respond will differ from one responder to another, according to the responder's purpose. In general, care should be taken to avoid sending useless or redundant responses, and to avoid contributing to mail loops or facilitating denial-of-service attacks. Your question is more tricky than what you thought... > It also looks as though Gmail sends these auto-replies to the return path > address instead of either the From or Reply-To, which doesn’t seem to me like > the right thing to do…. Same RFC : 4. Where to send automatic responses (and where not to send them) In general, automatic responses SHOULD be sent to the Return-Path field if generated after delivery. If the response is generated prior to delivery, the response SHOULD be sent to the reverse-path from the SMTP MAIL FROM command, or (in a non-SMTP system) to the envelope return address which serves as the destination for non- delivery reports. François ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Abusix Potentially Compromised Account Report
On 3/24/20 11:36 AM, Steve Freegard via mailop wrote: > I also found that I wasn't discarding some drive-by stuff which is more akin > to > what you were talking about so I've also corrected that which will further > reduce the noise, raise the quality and reduce the number of daily reports > being > sent. Hi, I have just checked the latest Abusix report I have received for free.fr accounts. Out of the 56 reported accounts, I have : - 8 accounts that have never existed (14.3%) - 2 accounts that do not seem to have ever used the hashed password. These acccounts have never been detected as compromised on my side. - 3 accounts that seem to have used the hashed password but changed it. These accounts have never been detected as compromised on my side. All other accounts (76.8%) have been blocked between 2015 and late 2018 (either their passwords their published in combo lists, or their accounts were detected as compromised) and all the hashed passwords were in my "compromised passwords" list. From my point of view, there has been a great improvement in your reports. But, AFAIAC, there are quite useless as (1) the data is quite old (even if the compromised passwords are still checked) and as (2) I am collecting the compromised passwords to be sure that a user will never reuse a password slightly modified. François ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Opinions? Email Abuse over TOR Network? (spamtraps)
On 2/22/20 7:47 PM, Alessandro Vesely via mailop wrote: > Even without 2FA, a password different from "12345" is probably desperately > hard to guess. _No_ When users tend to re-use the same password on different web sites or a slightly different password from site to site, guessing a password might be quite easy. On a domain I will not specify : - ~5% of accounts have been compromised - ~8% of accounts have at least one compromised password associated to their email (as I do not spend that much time to retrieve lists of compromised accounts, this figure is probably below reality) - these accounts have in average 2.7 compromised passwords (same comment) Once an account is compromised, many users do not realize what it really means and try to reset the password to the previous one or use a very basic transformation (just like using 'Password12' instead of 'password' or 'mybaby2003' instead of 'mybaby03'). If an attacker have a few compromised passwords associated to an email, he may easily guess which part of a password is re-used and which part are modified. It looks like we are experiencing such attacks here. François ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Avoiding bounces - custom spamfilter behind real-spamfilter that reject mails
On 10/24/19 2:19 PM, Stefan Bauer via mailop wrote: > Sometimes, customers feel clever and have another local mailfilter on > site, that rejects mails, after we already have accepted them at > spamfilter level. > So the reject generates bounces at our spamfilters. Howto handle this? _If_ your clients manage their own servers, your spamfilters may act as proxies (you just need to store the EHLO/MAIL FROM and delay the DATA to analyse the mail before sending it, all other commands may be proxified directly). The main issue with this kind of setup is to manage multiple recipients on different servers (ie when a mail is accepted for some recipients and rejected for others). By managing their own servers, I mean they have a way to setup their servers to put special rules about your IPs (such as accept xforward, avoid blacklists on your IP, etc.). François ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
