When a genuine invoice SMS looks like a scam: a forensic investigation

The infrastructure appeared genuine, but that did not establish the obligation, any underlying service or the intended recipient. This investigation separates what was observed from what remains unverified.

An unexpected invoice SMS named Melbourne Pathology, used a shortened link and supplied a telephone number. Its design created a difficult verification problem: several elements aligned with genuine organisational infrastructure, while the underlying payment request remained unproven.

The message received

SMS received — privacy redacted

“Dear [recipient], your Melbourne Pathology invoice for $80.00 is now overdue. Visit [recipient-bound link redacted] or call 1300 105 640 to discuss. If you have recently paid, please disregard this message.”

The recipient name and recipient-bound payment link have been removed. The transcript records what the message alleged; it does not establish that the invoice existed, was accurate or belonged to the recipient.

That distinction is the central lesson from this case:

Genuine infrastructure can support an unverified or misdirected payment request.

The safest response is not to decide whether a message merely “looks real”. It is to verify the organisation, the obligation and the intended recipient as separate questions.

The three questions we investigated

We divided the investigation into three parts:

1. Was the observed infrastructure associated with the organisation named in the message?
2. Did the available evidence prove the claimed obligation?
3. Did the evidence prove that the message reached its intended recipient?

These questions are related, but they are not interchangeable.

A genuine domain does not prove a debt. A functioning payment page does not prove that a particular person owes money. A message sent through a real system can still be misdirected or generated from inaccurate records.

First-party facts

Melbourne Pathology says it forms part of Sonic Healthcare, an Australian-owned diagnostic medical company.

The official Melbourne Pathology Accounts & Bill Payment page identifies 1300 105 640 as a telephone-banking number available 24 hours a day, seven days a week.

The message presented that number as one to call “to discuss” the invoice. The number therefore aligned with a first-party billing channel, but its officially published purpose did not align precisely with the message’s wording.

This discrepancy does not prove fraud. It means the number should not automatically be treated as an appropriate channel for discussing whether an obligation exists or whether a message reached the correct person.

Technical observations

Digital Sanctum examined privacy-redacted evidence through a bounded process that did not submit personal, account or payment information. The evidence and limits are documented in the methods and technical evidence appendix.

The redirect led into Sonic-associated infrastructure

The captured shortened address redirected into a payment environment whose network, domain and publicly visible organisation configuration aligned with Sonic Healthcare and Melbourne Pathology according to the preserved technical observations.

In plain terms, the payment environment openly identified the relevant organisation in its normal public configuration; this was not inferred from private account information.

Taken together, the captured redirect, Sonic-owned payment network, public Melbourne Pathology configuration, first-party billing number and corporate records support high confidence that the observed infrastructure was controlled by, or operated for, Sonic Healthcare or Melbourne Pathology within the limits of the investigation.

This is an infrastructure finding. It does not establish that the payment request was accurate, that an obligation existed or that the message was correctly addressed.

The short-link server supplied an incomplete TLS chain

Transport Layer Security (TLS) is the system browsers and other clients use to authenticate a website and encrypt a connection.

During the captured tests, clean Python, curl and OpenSSL clients could not validate the short-link origin because the server supplied its leaf certificate without the complete certificate chain those tested clients needed to establish trust.

The bounded description of this result is an incomplete served TLS chain. It is not evidence that the server was compromised.

The final payment host behaved differently: its certificate chain validated normally in the same testing context across the tested clients.

This contrast explains how one part of the journey could produce a certificate error while the final destination appeared technically normal. It does not establish whether the payment request itself was valid.

The path appeared to carry recipient-bound state

The captured path contained an opaque value whose observed behaviour was consistent with a recipient-bound workflow in the preserved, non-invasive test.

The original link, its identifiers and its technical structure are deliberately not reproduced.

Inference: possible bearer-link behaviour

The recipient-bound path suggested what is commonly called bearer-link behaviour: possession of a complete link may be enough to reach a particular workflow without proving that any protected information was accessible.

That is an inference, not a confirmed vulnerability.

We did not alter identifiers, enumerate records, test adjacent values, attempt unauthorised access or determine whether information could be exposed beyond the supplied path. No conclusion can therefore be drawn about exploitability or an access-control failure.

What the evidence supports

The available evidence supports the following findings:

• High confidence: the observed redirect and payment infrastructure were controlled by, or operated for, Sonic Healthcare or Melbourne Pathology based on the combined attribution evidence.
• Observed technical issue: the short-link server supplied an incomplete TLS certificate chain to the tested clients during the captured tests.
• Observed contrast: the final payment host validated normally in the same testing context during those tests.
• Observed purpose discrepancy: the supplied number appears on the official Melbourne Pathology billing page as a 24-hour telephone-banking channel, while the message presented it as a number for discussion.
• Reasonable inference: the opaque path appeared to carry recipient-bound state consistent with bearer-link behaviour under the limited observation performed.
• Not tested: whether changing, guessing or reusing an identifier could expose information or another record was outside the authorised method.

These findings make a simple fake-website explanation less likely. They do not prove that the message was correct.

What remains uncertain

The investigation did not establish:

• that the claimed obligation existed;
• that the requested amount was accurate;
• that any underlying service had been provided;
• that the recipient had a relationship with Melbourne Pathology;
• that the telephone number belonged to the intended recipient at the relevant time;
• that the message was generated from accurate records;
• that the recipient-bound workflow could expose information to someone else; or
• that payment through the link would have discharged a valid obligation.

A genuine-but-misdirected message remains plausible.

Stale contact information, a data-entry error, a reassigned mobile number or another administrative mismatch could also explain the message. These are possible scenarios, not established causes. The available evidence does not determine which, if any, occurred.

Why genuine is not the same as safe to pay

Payment messages require at least three separate judgements.

Is the infrastructure genuine?

In this case, the evidence strongly indicated that the observed infrastructure was genuine within the documented attribution limits.

Is the obligation genuine?

Unverified. Infrastructure ownership cannot establish the underlying account history.

Is the message intended for its recipient?

Also unverified. A genuine system can send a correctly formatted message to the wrong person or telephone number.

Separating these questions protects against both impersonation scams and genuine administrative mistakes. In either situation, paying or disclosing information before independent verification creates avoidable risk.

A safe independent-verification decision tree

Australian Government Scamwatch guidance recommends stopping and checking unexpected requests before acting, including contacting an organisation using details found independently rather than those supplied in a suspicious message. See Ways to spot and avoid scams.

1. Were you expecting the message?

No or unsure: Do not open the link, reply, call the supplied number or provide identifying information.

Yes: Continue independently. An expected message can still contain an error or be impersonated.

2. Can you locate the organisation without using the message?

Type a known official address yourself, use a trusted bookmark or obtain the organisation’s details from a reliable independent source.

Do not rely solely on:

• a shortened link;
• a number supplied in the message;
• caller ID;
• a search advertisement; or
• a reply from the same messaging thread.

3. Does the independently located channel match its claimed purpose?

Check what the official website says the number or channel is for.

An automated telephone-banking number may accept payments without being suitable for discussing whether an account exists or whether recipient details are correct. To verify an obligation, use an independently published billing-enquiries or general-contact channel that explicitly supports that purpose.

4. Can the organisation verify the matter from its own records?

Ask the organisation, through an independently obtained channel, to confirm:

• whether an obligation exists;
• whether the contact details on file are correct;
• whether its systems generated the message; and
• how to obtain an invoice or statement independently.

Do not disclose more information than necessary. If the organisation cannot verify the matter independently, do not proceed with payment.

5. Is the message clearly not for you?

Do not access the linked workflow or try to identify the intended person.

Report the possible misdirection through an independently sourced privacy, billing or general-enquiries channel. Delete the message when it is no longer needed, subject to any legitimate need to preserve evidence.

6. Have you already provided sensitive information?

Contact the relevant financial institution through an independently obtained number if you supplied credentials, financial details or other sensitive information.

Scamwatch provides further guidance on what to do after a scam or suspected scam.

Do not continue testing the link yourself.

Practical lessons for organisations

Avoid opaque links where possible

A shortened or recipient-bound link conceals its destination and asks people to trust the message before they can verify it. A safer design directs recipients to a well-known public website and lets them navigate independently to a secure account or billing area.

Match contact wording to the channel’s purpose

If a message says “call to discuss”, the supplied number should lead to a channel authorised and equipped to hold that discussion. Using an automated payment number for that wording creates ambiguity precisely when the recipient needs reassurance.

Serve complete certificate chains

An omitted intermediate certificate can cause validation failures in some clients even when other software completes the chain successfully. In this investigation, the incomplete chain caused failures in the tested Python, curl and OpenSSL clients without showing compromise.

Treat recipient-bound links as sensitive

Links carrying access state should be minimised, expire appropriately and avoid revealing information before proportionate verification. Difficult-to-guess identifiers are not, by themselves, a substitute for considered access controls.

Design for misdirection

Telephone numbers change hands, records become stale and messages can reach unintended people. Notifications should disclose as little as possible before identity is established and provide a clear, independently verifiable way to report an error.

Limitations

This was a bounded, non-invasive investigation.

We analysed preserved evidence, public corporate and billing information, DNS and network observations, TLS behaviour, HTTP redirects and publicly visible organisational configuration under the documented method. We did not submit forms, make a payment, contact the organisations, perform a personal-data lookup or test access-control boundaries.

The testing recorded system behaviour at a particular time. DNS records, certificates, hosting, redirects and public webpages can change.

We did not have access to internal messaging records, billing systems, account history, consent records or telephone-number provenance. Those records would be needed to determine why the message was sent and whether it was correctly addressed.

The investigation therefore supports an infrastructure assessment, not a finding about any individual obligation.

Conclusion

The message was not adequately described by either “obvious scam” or “proven genuine invoice”.

The observed infrastructure strongly aligned with Sonic Healthcare and Melbourne Pathology according to the combined attribution evidence. The short-link server supplied an incomplete TLS chain to the tested clients, while the final payment host validated normally in the same bounded testing context. The supplied billing number was genuine, but its published purpose did not match the invitation to call and discuss the matter.

Most importantly, none of those findings proved the obligation or the intended recipient.

The proportionate response is to avoid the embedded path and verify the matter through contact details obtained independently. That approach remains safe whether a message is fraudulent, genuine, erroneous or misdirected.

Digital Sanctum investigates ambiguous digital systems by separating what the evidence proves from what it merely suggests. Explore more evidence-led security and infrastructure analysis in Digital Sanctum Insights.

Methods and technical evidence

This appendix provides a privacy-safe, reader-resolvable evidence note for the original technical observations. It excludes the message text, recipient details, recipient-bound identifiers, account or payment information, raw paths, endpoint syntax and instructions that could enable unauthorised testing.

Scope and boundaries

Digital Sanctum reviewed a preserved, privacy-redacted evidence set and conducted bounded observations of the supplied infrastructure. The method covered redirects, domain and network attribution, DNS, TLS certificate delivery, HTTP behaviour and publicly visible organisational configuration.

No forms were submitted. No payment was attempted. No personal-data lookup, identifier alteration, enumeration, adjacent-record testing or access-control probing was performed.

Infrastructure attribution

The captured redirect terminated in a payment environment associated with a Sonic-owned network. Publicly visible configuration in that environment identified the Melbourne Pathology organisation, while first-party corporate material established Melbourne Pathology’s relationship with Sonic Healthcare.

The redirect, network ownership, public organisational configuration, official billing number and corporate record were assessed together. This combination supports high confidence that the observed infrastructure was controlled by, or operated for, Sonic Healthcare or Melbourne Pathology.

This attribution applies only to the observed infrastructure. It does not authenticate the underlying obligation, establish who initiated the message or identify its intended recipient.

Short-link TLS observation

The short-link origin supplied its leaf certificate without the complete chain required by the tested clean Python, curl and OpenSSL clients. Those clients consequently failed certificate validation at that origin.

The observation is accurately described as an incomplete served TLS chain. It does not demonstrate interception, compromise or malicious control. Other clients may behave differently if they already possess or retrieve a missing intermediate certificate.

Final-host validation

The final payment host supplied a certificate chain that validated normally in the same testing context. This was a technical contrast with the short-link origin, not evidence that the payment request itself was correct.

Recipient-bound state

The supplied path contained an opaque value that appeared to preserve state associated with a particular workflow. Its behaviour was consistent with a recipient-bound design.

The observation was limited to the supplied path. No identifiers were modified or compared, and no attempt was made to determine whether another record could be reached.

Bounded bearer-link inference

The observed recipient-bound state was consistent with possible bearer-link behaviour, in which possession of a complete link may grant access to a defined workflow.

This remains an inference because access-control boundaries were not tested. The investigation found no basis to conclude that records were enumerable, that unrelated information was exposed or that a vulnerability was exploitable.

Non-public evidence provenance

The underlying governed records are retained privately because publishing them could expose restricted recipient-bound material. The evidence records used for this article were:

• Forensic recovery pack 1/4 — technical and infrastructure findings.
• Forensic recovery pack 2/4 — citation and first-party evidence.
• Forensic recovery pack 3/4 — editorial, privacy and publication controls.
• Forensic recovery pack 4/4 — integrity and chain of custody.

These retained evidence records are not public downloads.

Sources

Public reader-facing sources

• Melbourne Pathology, About Melbourne Pathology.
• Melbourne Pathology, Accounts & Bill Payment.
• Australian Competition and Consumer Commission, National Anti-Scam Centre, Ways to spot and avoid scams, Scamwatch.
• Australian Competition and Consumer Commission, National Anti-Scam Centre, What to do if you’ve been scammed, Scamwatch.

Non-public forensic provenance

The privacy-redacted technical findings and chain-of-custody records are identified in the non-public evidence provenance section. They are not published because the underlying records contain restricted recipient-bound material.