Re: [mailop] Compromised email account trends
That's exfiltrating the useful information of the compromise without needing to maintain control of the device, keep records, or have a bot controller. On 22/2/23 09:14, Jarland Donnell via mailop wrote: Forgot to add on to this: If your SMTP hostnames, as your customers would configure in Outlook, is a strange and very unlikely thing for them to send in the subject of an email, you can also catch these even earlier. This is a censored example of an email subject sent by this virus today: T="longhorn.mxrouting.net 587 u...@domain.tld password" It seems to pull hostname, port, user, and pass to combine and make an email subject. As best I can tell, from Outlook config files. On 2023-02-21 17:04, jarl...@mxroute.com wrote: Great post! Got another one for you all today: coteru...@gmail.com This one hit one of our customers pretty hard (password reuse, virus, bad variables). On 2023-02-21 12:10, Steve Freegard wrote: I recently wrote an entire blog post on this topic that might be of interest: https://abusix.com/resources/blocklists/compromised-account-detection-with-abusix-mail-intelligence-and-postfix/ It's based on Postfix, but adapting this for Exim shouldn't be difficult. Kind regards, Steve. On Wed, 8 Feb 2023 at 13:48, Jarland Donnell via mailop wrote: Hey everyone. I've been thinking about how I could add some more value to this list and there's one thing I've been working on for a while that I think will be really helpful to share. Email accounts get compromised. It happens. Especially when using base standards (IMAP/POP/SMTP) that inherently lack two-factor authentication mechanisms. As I discover ways to identify when accounts have been compromised, I'd like to share them with you all. Today I discovered a new trend based on an abuse complaint, which allowed me to further identify several compromised user email accounts across our platform. I'd like to share with you the headers and body, censored of any customer information, that was sent to me in an abuse complaint (I also removed the recipient that actually reported it): https://paste.mxrouteapps.com/?862a67d53b18e8df#2k9DaEP1V9pPe6Th5CmeMS4JbyD38ZkTdDoLpYuWEvcT I expect that this bad actor will change their behavior, and I'll of course adjust. However, if you turn your attention to these two variables in your logs today you will find anyone who has been compromised very recently by this actor: 1. Email subject appears blank in logs (ex. T="" in exim log) 2. The first recipient they send to is jackgrelesh...@gmail.com If you find someone sending email to jackgrelesh...@gmail.com on your platform today, most especially with a blank subject, I will gladly take the beating for you if you suspend the user and find it to be a false positive. The idea that following these trends could produce a false positive has, in my case at least, proven to be more of a rough theory than a reality. Some bonus indications of similar but different compromises: - Any email sent to ollegas2...@gmail.com, glob22aa.fun, or mx373.com [1] consistently links to what I believe is a virus that sends out a user's email credentials to the bad actor. Keep up the good fight friends. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop -- Steve Freegard | Senior Product Owner T. +44 7740 364348 abusix.com [2] Book a meeting [3] [4] [5] [6] [7] CONFIDENTIALITY This email and any attachments are confidential and may also be privileged or otherwise protected from disclosure. If you are not the named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose, or store or copy the information in any medium. You’ll find further information about privacy here [8]. Links: -- [1] http://mx373.com [2] https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzZTf64_AIC7pyl-xmo2L5eYJtYu1PnTYrDUUBmQW-VxiqyfDuPS_3WZnIEFz1xocGdBhnxAEyhHhg3_G29KPX5gu0-0JxXoL3Lw4zV1rZI4zA5EgDWnGc90iUX1HRTDIs= [3] https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDzdypi6WPqhVkFKkuLiMX0pY_5fawxs7P25-lwfZUyr7w== [4] https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDyIo6EwBskR6pg3M12nuwEx_9G03qmurLHy8H_IjsK3cg== [5] https://cloud.letsignit.com/collect/bc/5fc7cedc63ed1d1d78e45272?p=3QW9LKZRNsNLctpv2M4xw66qtjrDbFHkRfe_Jo_T8nLiDvwE1FDvAnv56cZf8gHOlGcXNTPUHN-wE0IIEJbWkBqUZ5n-wh878kG0mKc-TDweOZAf2SFcCyyLHlLyd4j2GB_p_YWWJ_3WJxEqTQND2A== [6]
Re: [mailop] Extreme multiple posting (was Re: OVH Bulk Mailer? Anyone know this one?)
On 8/8/20 7:31 am, Jaroslaw Rafa via mailop wrote: > Dnia 5.08.2020 o godz. 11:16:05 Large Hadron Collider via mailop pisze: >> you know, Mr Allard, it appears that you sent this message to the list at >> least 5 times... > > I have received it only once. Maybe it's something on your side. Mailop > server seemed to have issues since Wednesday, my message to list was staying > in queue with 421 response and I didn't receive any messages from list. They > did pass through today. > I received the message 43 times over a period of 21 hours starting at 2020-08-05 14:04:23 UTC. After junking the message id, it was blocked a further 52 times. The last one being at 2020-08-07 12:31:22 UTC. This is the only message (that I know of) I've had issues with. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Abusix Potentially Compromised Account Report
Has anyone run into "Abusix" /potentially/ compromised account notification emails before? Their website "abusix.ai" looks to be about a week old based on the age of all of the articles. I would have guessed they'd have been around for longer and their name does ring a bell. Blog announcement on Abusix.com would indicate they launched Mar 2019. They've sent us a report from "nore...@abusix.org" to postmaster@ here in some kind of misguided attempt to help us because "Over the last 24 hour period our traps have detected 1 potentially compromised accounts on your domain." In the CSV they attached, apparently the IP address 185.234.219.89 (Poland) attempted to send an email at 2020-03-19T17:59:03.000Z using smtp auth credentials apparently from a domain hosted here. That IP address is not at all related to any networks or servers for the domain. They do provide the first 5 characters of the sha1 of the password that IP address used. I know it used the wrong password because the account in question does not have a password - it's an alias and not an account. Given the number of fraudulent auth attempts we all get every day with wild and whacky unrelated usernames (I get hotmail & others provided as username), why would anyone think it was a good idea to send out spam to stop spam when it was clearly a fraudulent email that didn't even go anywhere? If everyone sent out a spam notification when someone abused a domain we'd all be getting 10x fold increase in spam, all trying to be "helpful". They do ever so helpfully provide an "opt out" link. I am scratching my head as to think when I opted into such a service. /sarcasm. My initial thought was to route their domains and IPs to /dev/null, happy in the thought that I now get one less domain's spam. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Anyone from Gmail ?
On 07/03/18 11:56, Dave Lugo wrote: > I completely agree. So, unsure how gmail should handle that. Be more > lenient on open rates? > > Could the bank transition some or all of that traffic to SMS, where it > might be less susceptible to spam blocking? Most of the banks here in Australia now have an App for your phone which gets push notifications of all messages. Email in that role is now playing second fiddle. Would Gmail take the time to monitor open rates for given senders? Given it'll be an AI spam filter, it could be used as an input, but I'm just guessing. Not something I have as a possible input, not even occurred to me. I'm still struggling to figure out if it would be a reliable indicator at all. signature.asc Description: OpenPGP digital signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Different From domain and Reply-To domain
On 08/12/17 01:17, Ken O'Driscoll wrote: > On Thu, 2017-12-07 at 14:50 +0100, David Hofstee wrote: >> Hi, >> >> Can people here share their experience (or spamfilter configuration) with >> differing 5322.From and 5322.Reply-To domains in larger volumes of >> email? > > Completely agree with Vladimir and Al, it's common practice. > > The only exception I can think of, is if the reply-to was a freemail > address. And, even then, you couldn't 100% assume the mail is bad because > legitimate users can use email in strange ways. Website contact forms also need to use the reply-to instead of from address when sending email to the site owner. The from address is the site, but the reply-to is set to the contact form user's address so that a simply reply ends up in the correct location. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Mailchimp / Mandrill App: European VS US Privacy Laws
On 11/06/16 09:29, Michael Wise via mailop wrote: > > ... when the server receives it, it gets authenticated. > Or did you forget this? That doesn't help when attempting to provide "proof" of signup at some future date - it will simply be a message with a DKIM sig that can no longer be confirmed. I don't store old key information and I don't think anyone else does. I'm not going to trust a 3rd party to say "it was signed when I got it! I swear!" - it may as well be made up. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Mailchimp / Mandrill App: European VS US Privacy Laws
On 11/06/16 05:02, Michael Wise via mailop wrote: > Well, the From: domain would be a good start. > > It would certainly cut down on the trivial forgeries, and could easily > be transferred from the web to email with a single mailto: link. Any signed DKIM message can only be authenticated while the key remains in DNS - I cycle mine once a month, and pull the key after that. Once it is no longer available, the signature may as well be made up. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] deprecating rc4 & ssl3
On 18/05/16 00:27, Al Iverson wrote: > Hey Brandon, can you explain regarding IMAP & POP being disabled? My > employer does a ton of automated email processing using Google apps > and Gmail accounts, using IMAP and POP (with SSL). Are IMAP and POP3 > being retired permanently? I suspect the IMAP and POP3 protocols are not being retired outright, but only the ability to connect to them using RC4 and SSL3 encrypted connections. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Failure reporting false positives to ClamAV
I recently attempted to report a false positive via their web interface. I think it's safe to say, they didn't get my report so I thought I'd include it here and hope they might be reading, along what appears to have gone wrong. Regrettably, there doesn't seem to be a channel to report a false positive false positive. http://www.clamav.net/reports/fp The domain reported were Paypal related, and used in ESP newsletters sent to Australian users. They are picked up as "Heuristics.Phishing.Email.SpoofedDomain" any time they go through - I can't whitelist as the system rejecting is not local. e [dot] paypal [dot] com paypal-exchanges [dot] com Details on their website of these domains is here: https://www.paypal.com/au/webapps/mpp/email-whitelist The report was submitted last night, but the failure became apparent this morning when I received a series of bounce messages from Cisco relays indicating that my message couldn't be delivered. I'll exclude further details as it appears to have been a rather large boo boo they wouldn't want repeated. Suffice to say, I will not be able to report these domains via the interface until the system is fixed internally. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] New method of blocking spam
On 25/01/16 08:57, Dave Warren wrote: > Bayes is good at categorizing mail, but I don't think "Trying to sell > something" is necessarily even a spam-sign, lots of legitimate and > desired mail is trying to sell me something too. At the same time, > everything I've read about this new method seems to be a slightly > modified bayes approach (with the twist of taking word pairs or triplets > into account) and I doubt it will be a real game changer, although it > may result in some new ways to tune bayes to increase effectiveness. There's nothing new about the twist - They're called Hapax legomenon, and it's been built into Spam Assassin for a while - earliest quick reference I can see is 2007. It's enabled by default. DSPAM also includes this ability. Token combinations (2-3 word hapax) are also an option for some program out there, but the instance eludes me at present. This is probably why no one is jumping up and down with joy at this FUSSP - we're all already using it. http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html > bayes_use_hapaxes (default: 1) > Should the Bayesian classifier use hapaxes (words/tokens that occur only > once) when classifying? This produces significantly better hit-rates. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Delivery to A record if MX exists ?
On 17/06/15 18:16, Kurt Jaeger wrote: I had a case where lb1-smtp-cloud3.xs4all.net delivered to an A record where an MX existed. Exchange machines will also try this if all MX defer, but if they get a 4xx/5xx error they ignore it. It's quite annoying but otherwise benign. If there was as client which paid attention to the random A host responses (when not 2xx), it would an issue. ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Sourcing an email related quote
On 05/05/15 12:14, Dave Pooser wrote: From Todd Lyons' .sig: The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine That is the one, thank you! I knew I'd seen it on one of the mailing lists somewhere but only remembered the gist of it. Now that I know the wording, I can find it everywhere. I just needed the perfect quote to reply to a whitelist request for a particularly poorly configured mail server. Mail server in question is an EC2 instance, generic PTR, greeting with .internal version, sending from different hostname level domain which doesn't accept bounces, no SPF/DKIM, a from address that is NXDOMAIN, with malformed multipart contents via custom PHP script. I'd say they couldn't do anything else wrong if they tried, but I've been asked to accept from worse. Cheers, Ted. ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
[mailop] Sourcing an email related quote
Hi all, Many moons ago, someone related to email said something which stuck in my head and gave me a giggle. I know kinda how it went, but now that I've tried to search for it and quot the person who said, I'm having no luck at all. The quote was related to delivery problems and how it is the sender's responsibility to at least try to make their sending servers not look like every other spam bot out there. What I can remember went something like this: Recipient's budget to deal with your delivery problems: zero. Does that ring any bells for anyone? Link to the source? I'm stuck in an infinite loop of treasurers talking about their countries' budgets when I start googling for it as all of the email related keywords are ignored. Have a good one, Ted. ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
