fyr.io

Atera Leaked Their Customers To Mailinator

Posted on

Atera is a Remote Monitoring and Management (RMM) and Professional Services Automation (PSA) tool used by many organisations to maintain endpoints and respond to support requests. Typically used by MSPs to access and support their clients, it has also found life within internal tech support teams thanks to its per-technician pricing model.

There was a slow data leak of active Atera customers (as in, the identity and helpdesk mailbox of customers of Atera - the MSPs that use Atera for their clients, or the companies who use Atera for their internal support, not any data belonging to the customers or their clients,) available to the public for at least 6 months. I noticed it in October 2024 and reported it, and it has been fixed as of May 2025.

It was, on the surface, a low priority & low impact information disclosure issue that affects the users of Atera who set up and test their SMTP config. It leaks no more information than the mailbox used to send emails, but a side effect (read: malicious opportunity) of this is that you can of course determine that a company is using Atera without interacting with them or Atera at all. It hasn't really got much of an impact outside of some timely social engineering scenarios, which I'll run through towards the end of this article, but thought that this was interesting enough to write up, given the potential damage that could be caused, and that it's basically just a silly implementation of a mail check.

The details

As with most RMM/PSA tools like this (of which there are many alternatives) you can configure Atera to send emails not from their email, but instead from your own chosen email address. One way it achieves this is by allowing you to input mailbox SMTP credentials, which it will then use to send all email. It will also monitor this inbox, automatically making tickets on its built-in helpdesk portal based on these emails.

A screenshot of the Atera Outgoing Email Domain configuration screen, with 'Customize SMTP settings' checked and relevant information added. The email field has been blocked out.

Within this configuration page is the option to test that it's working. I wondered how it tested this, so I hit the Test button, opened up the Sent items on the mailbox, and...

A screenshot of gmail showing the test email that Atera sent to validate that the configuration used is working. The test email has been sent to a mailinator email address.

Unfortunately, Atera implemented this test using a public mailinator mailbox.

Mailinator is a service that provides you with a completely open mailbox. As in, you don't need a password to see the emails. It's useful to sign up to websites or services you don't really care about. All you need is an alias (the bit before the @) and you can open any @mailinator.com mailbox. By design. It's a great service with paid options that offer many additional features.

As you can see in the above screenshot, when testing SMTP via Atera, Atera sends an email from your configured mailbox to mailinator, likely checking the result of this in the background to determine that the mail has arrived. To be specific, they send it to atera_test_email@mailinator.com, which you can view here.

If you were to sit and watch this mailbox you'd see mail flow in occasionally as admins configure and test their SMTP config.

Mailinator offer a free private mailbox, which works exactly the same except the mailbox isn't visible to the public. If they had registered and switched over to this private mailbox it would probably be mostly fine.

A screenshot of the mailinator inbox with nine redacted emails in it from several different organisations.

This is a problem, although it is a pretty low priority and low impact one, but I thought it worth writing about as with many things like this, add a bit of imaginations and there is a risk here. Interestingly the emails in the mailinator inbox get removed fairly quickly, though this is inconsistent. I suspect Atera cleared out this mailbox in the background on a schedule.

Theoretical abuse

Let's daydream a basic, theoretical phishing attempt using this knowledge!

I imagine someone nefarious monitoring this mailinator mailbox and, upon reciept of an email, firing off their own email to the email address that sent the test email, which will most likely appear right into the ticket queue on Atera of the customer who just tested it. This email could pretty easily look like it's from Atera themselves. Perhaps it celebrates them configuring their SMTP settings correctly! Maybe they could offer them a celebratory free month subscription? Something enticing. All they need to do is click this link to verify their account and the discount will be automatically applied.

An unaware tech (or perhaps even the account owner who set up SMTP) may be tricked into clicking this - they literally just set up SMTP, how would a bad guy know that? Their browser loads the link to an atera-lookalike domain. They login and submit 2fa (because they trusted that email, remember?) and now the bad guys have easy access to what could potentially be an MSPs client base, which could reach into the hundreds of separate companies and organisations, tens of thousands of endpoints, or more.

Reporting Timeline

At this point, I ran some tests and confirmed that the issue has been resolved. They now send a test email from the mailbox back to itself and to the individual who requested the test, which is perfectly fine. Mailinator does not see any mail.

This concludes this little episode of a minor but abusable Atera data leak! I'm trying to get back into the world of infosec in a more active way (I've been passive for a long time) and have a couple other things I'm working on. Hopefully I can start to build some momentum!