But why would a Swiss based business reporting as tryngo-services.com be sending email correspondence with a MyGov header?
One source lists 11 employees with some not so Traditional Swiss names.
Because their email server has been hacked/access inadvertently given to scammers (phishing) to allow them to perpetuate their scams.
1 Like
One answer is: the perils of outsourcing. An absolute mass of email arrives from servers that bear no apparent relationship to the actual source of the email. That is just the way it is.
Has the Australian government outsourced some email handling function to “tryngo services”? Probably not but you can’t rule it out.
But you can probably rule out an email containing links to reply through. The template for any other MyGov emails directs one to independently log into MyGov to access the MyGov secure messaging service from your user login.
On a tangent it is common for emails to be received these days following up customer service or more generally encouraging adhoc customer feedback. All include an email link to a feedback dialogue/survey. But it could lead many other places. There is no option to do so through a more secure login to the service independently fly to access the survey.
Are we now at a point that the rule is to ‘never click on an embedded link’ regardless of the email source?
As scammers become more aware of what is common place will we see more scam emails that are near perfect replicas of content we have come to trust everyday. Choice relies on members responding to emailed requests to support various campaigns, using embedded links. How many older Australian’s and not so digitally literate know how to assure the web address behind the link is not mischievous?
P.S.
As much depends on the device email client behaviour as to the digital savvy of the user. The example I provided displays in Thunderbird with the senders return email web address displayed after the supposed ID, a clear indication of a discrepancy. Apple on an iPad only displays the supposed ID. One needs a little more knowledge to bring up the senders supposed true web address. This assumes one bothers to check. By default Thunderbird blocks remote content in the message. Apple does not! Norton detects no issues with the sender or email!
1 Like
Yes, exactly. Again, outsourcing bites you on the arse. It is not a 100% indication of scam just because a link goes somewhere with no apparent relationship to the actual source.
In a work environment, it can be even worse. When I receive email at work, links in emails are replaced by links to anti-malware scanning - that will redirect to the original destination if it passes security scanning and otherwise will be blocked in some way (which means of course that I can’t personally decide whether I want to click on the link by seeing where the link is going to go).
True.
As suggested even emails from Choice can lead directly to a non Choice site for surveys or other purposes.
How does email interception work? I have been told that it is so difficult that it is hardly a feasible method of running a scam. Is that right?
This article says email interception was used to run a variation on the old fake invoice scam. Is it true?
1 Like
It is true, and happens frequently. Email is not designed to be secure.
An article on this.
Is It Possible to Intercept Email and How? - Guardian Digital..
In addition to interception, emails can be read and copied from where they are stored on servers or clients and used to create malicious new emails.
1 Like
Thanks. So the ‘intercept’ can be based on accessing the email server. I think the information I was given was about interception of packets in transit which is another matter. Given how many servers get compromised and allow business data to be extracted it is no great stretch to see emails getting replaced or edited.
This suggests to me that, assuming your own system is well secured, the core problem is doing with business associates whose systems are not.
Intercepting the packets flowing across networks is certainly doable. I used to do it a lot for IT problem determination using hardware ‘sniffers’ or packet analysers, or at the software side using tracing and logging.
With emails the protocol widely used is SMTP and the packet content is plain text generally. As is web page content using HTTP.
One day we may see a widely used email transfer protocol using encryption in the same way that HTTPS is now pretty much standard for web page content. We may also see the day when the header fields like ‘sender’ cannot be changed.
Is it also easy to ensure you have all the packets and to re-assemble them into the email so that you can edit it and re-send?
It is not hard to recreate an email from the packets.
There are three common protocols used to deliver email over the Internet: the Simple Mail Transfer Protocol (SMTP), the Post Office Protocol (POP), and the Internet Message Access Protocol (IMAP). All three use TCP , and the last two are used for accessing electronic mailboxes.
Every packet in TCP has a sequence number in the header. This is used to reassemble the content that has been split into smaller bits back into the original content. The protocol indicates the start of a sequence, and the end. Just have to follow the sequence numbers to put the email back together.
How hard is it to ensure that get them all?
Easy. The TCP protocol ensures that all packet content is sent, or perhaps resent, and the sequence information enables the correct assembly into the correct order even if packets arrive out of order.
That is unlikely and unnecessary except for nation state hackers. Mostly it is just compromise at one or both endpoints i.e. mail client or mail server.
While most email content is itself unencrypted, most1 email is transmitted from one server to another with the STARTTLS command having been used, so it can’t be intercepted in transit even by nation states unless the underlying encryption is broken.
Of course there is also the potential for exposure when the client retrieves the email using POP or when the client accesses the email using IMAP. I would suggest that most commercial providers default to using POP over TLS / IMAP over TLS. So, again, fairly robust against interception in transit.
1 Totally unscientific claim 
based on operating my own mail server i.e. strictly anecdotal evidence. When sending out mail, my mail server always attempts to use STARTTLS if it is offered by the server and always notes when this is not achieved - and it can fail to be achieved for a number of reasons e.g. not offered, self-signed certificate, other problem in certificate authority chain, wrong domain on certificate, expired certificate, incompatible protocol versions, incompatible encryption algorithms, …
As @gregr says, it is relatively straightforward to get the entire TCP session and you should always assume that that is occurring if the overlying data is not encrypted.
The only real challenge is “routing”. It is not beyond the realms of possibility that packets in a given TCP session take different routes between the source host and the destination host. Success can therefore depend on where in the path your adversary is - or whether your adversary can intercept at multiple points.
Example: If you are using an untrusted public WiFi access point then obviously there is only one choice of route at the beginning of the path i.e. the access point reliably sees all traffic - and if you aren’t encrypting (above the link level) then you should assume that the access point has the entire TCP session.
Example: If you are communicating with a host in the US then there are many many routes to the host but you can assume that the US government is intercepting all of them - and probably storing all the traffic - and if your traffic is of interest, reassembling the TCP session.
Well tell that to some who have used the “striptls” technique to turn off starttls.
Better would be to standardize on all email transmitted on client to server, and server to server using SMTPS and POPS, and IMAPS using the secure defined protocols and the ports defined. Just like HTTPS.
1 Like
Ha ha, yes. I have configured so as not to reject such a downgrade attack - because a few too many server destinations would legitimately fail. One mitigation for that attack is to remember which servers previously accepted STARTTLS and reject if they suddenly start not offering or not accepting STARTTLS. (This is somewhat the way HSTS works for HTTP.)
Eventually STARTTLS will be solid because 99%+ of receiving servers will support TLS and all sending servers will reject failure to send without successful STARTTLS. (So stripping STARTTLS simply becomes a DoS attack.)
Unfortunately IETF/IANA botched that (port 465 was registered by IANA and used de facto by some software, then deregistered, and never documented by IETF) … so it may be too late. Everyone has just gone off and used STARTTLS with port 25.
1 Like
It is somewhat an optional facility, although one would think these days most email servers and clients would support STARTTLS over port 25, and reject emails from places that did not turn it on.
Doesn’t help that RFC3207 maintains that emails must not be rejected coming from servers that do not upgrade the transmission to use TLS.
1 Like
My interpretation of that RFC is that
- the receiver must not require STARTTLS
- the sender may require STARTTLS
and it is the latter that I was suggesting.
As long as one end (at least) requires STARTTLS then it is solid - and the RFC gets it right in leaving the choice exclusively to the sender.
1 Like
Lots of red flags with this attempt to fool you. Who knows what damage clicking on the button might do, or requests it might make of one’s account details?
Unfortunately our national level of digital literacy and coercive transition to non contact banking will likely to see emails such as these succeed often enough. It came from a personalised foreign email address. This may or may not be immediately obvious depending on the email client used. It had no problem sneaking passed Telstra.
P.S.
Added to ScamWatch’s reporting data base.
4 Likes
