View password of attempted login - UTM 9

A well-designed system does not put passwords into log files.  If a legitimate user cannot log in, they can and should call for a password reset.  You may be able to capture what you want using tcpdump, if you know when the connection attempts are arriving, but I cannot imagine why you think this will be helpful.

We detect many, many SMTP Authentication failures every day, from random devices looking for open relays or some other attack strategy.   Periodically, I identify the most annoying sources and then I blacklist the IP address.

Your UTM should not allow authenticated SMTP/POP/IMAP to a UTM address.   Those function should be directed to your email server.

A well-designed system does not put passwords into log files.  If a legitimate user cannot log in, they can and should call for a password reset.  You may be able to capture what you want using tcpdump, if you know when the connection attempts are arriving, but I cannot imagine why you think this will be helpful.

We detect many, many SMTP Authentication failures every day, from random devices looking for open relays or some other attack strategy.   Periodically, I identify the most annoying sources and then I blacklist the IP address.

Your UTM should not allow authenticated SMTP/POP/IMAP to a UTM address.   Those function should be directed to your email server.

I will try TCPDUMP.

To help you imagine why this would be helpful, if someone is trying to authenticate with a once valid password from a foreign country, then it wouldn't be a brute force attack.  It would mean they have other access already.

This would not be a proper role to use your UTM as a solution for - this would fall under a legitimate identity access and management (and preferably monitoring) solution instead. On the other hand, you should never need to know what password is being used, because once you know a credential is being attempted illegitimately (you already seem to know if the attempt is legitimate or not), then you know the credential being used; so, from that, you can deduce who needs to go change their credential just in case. Any unusual activity of a credential should prompt action on that credential just to ensure there is no "once valid password" - as soon as it is changed, it is no longer valid, as users should never be allowed to reuse passphrases.

I do not think there is any viable way to use OTP with authenticated SMTP.   I infer that you are tying to connect a remote Outlook (or equivalent) email client to your mail server, and the connection uses POP3+SMTP or IMAP+SMTP.   SMTP is only needed to send messages, and this is relatively infrequent.   Consequently, one can assume that either the mail client or the mail server will drop the connection do to idle timeout.    So even if your user gets the OTP entered fast enough for Outlook to do its send-receive test sequence, the remembered password will be wrong when the user tries to send a real message.

It might work with DUO, because DUO accepts the login and does a secondary authentication by another process.   But it is likely that the number of secondary verification steps will drive most users crazy.  DUO is free if you only have 10 users, after that you pay for everybody including the first 10.

You have many other options for remote access to email which would support 2-factor authentication, including web access via a WAF site, SSL VPN Client, or HTML5 VPN to RDP or Web.

Even without those, a connection based on ActiveSync or EWS is more likely to work with your scheme, as the connections are likely to be more long-lived.

For cell phone 2-factor authentication, the best solutions are third-party products that link your phone to their gateway using a mix of digital certificate, sandbox mail application, and hardware fingerprinting.   Then their gateway connects to your mail server on behalf of the phone.

You guys are over thinking this.

Someone is testing username/password combo's by trying to authenticate to the UTM's smtp.   

Legitimate users do not authenticate to the UTM 9's smtp, they authenticate to exchange and exchange passes the mail to the UTM as a smart host.

I was able to capture the Base64 encoded passwords by using tcpdump on the interface and filtering by the source IP address found in the User Authentication daemon log.

From that we were able to confirm if connection was attempting to use a leaked password.

Thankyou for your help.

Hi Paul and welcome to the UTM Community!

Interesting solution.  I'm curious - where did you find auaconfig.pm?

If you check Basic Exchange setup with SMTP Proxy, you will see that enabling 'Authenticated Relay' is not recommended.

Cheers - Bob