Dodgy Dave spoofs a parcel company to steal card details¶
Dave sends fake missed-delivery emails that display a parcel company's genuine address. He thinks the familiar From address will settle the question of who sent them. This offender-viewpoint scenario follows what Dave changes - and the delivery, website, payment and device evidence he still creates.
Dave can alter what one field displays. He cannot make every independent system involved record the same fiction.
Scenario note: This is a fictional training case viewed from the offender's side. It is separate from the supplier-payment investigation in EML-046. Names, organisations, domains and records are invented; the .example domains are reserved for documentation.
Dave's plan¶
Dave copies the logo, colours and wording used in genuine parcel notifications. He does not use a slightly misspelled version of the company's address. He puts the company's real address - tracking@parcelpost.example - in the message's From field.
He has not accessed that mailbox. His sending software simply presents the address he supplies. Dave is relying on the recipient, and perhaps the investigator, stopping at the first fact.
Hello,
We tried to deliver your parcel today. A redelivery fee of £1.74 must be paid before it can be released.
Arrange redelivery
ParcelPost Delivery Team
Dave spoofs the real From address¶
Dave sends the campaign through infrastructure unrelated to ParcelPost. The message reaches the recipient carrying the exact address he chose, but the systems that handled it record a different story.
tracking@parcelpost.exampleThe genuine-looking From address means ParcelPost sent the message.sending route → recipient providerWhich external system delivered it, and was that route authorised for the displayed domain?The visible From field describes the identity presented by the message. It does not, by itself, identify the account, infrastructure or person that created it.
See the difference between Dave's story and the evidence route
Whether either service can identify a customer, session or payment must be established from its records. The address on screen does not answer that question.
The receiving system records something different¶
The recipient's provider accepts the message and adds its own delivery and authentication information. A simplified extract might look like this:
SPF and DKIM can pass for the unrelated campaign service while DMARC fails because those authenticated domains do not align with the ParcelPost domain displayed in From. The results do not say, “Dave sent this.” They support the narrower conclusion that the receiving system did not record an authenticated, aligned route for ParcelPost.
Dave sends the recipient somewhere else¶
The button labelled Arrange redelivery goes to parcel-redelivery.example. The visible wording says nothing about that destination. The page asks for a £1.74 payment; the small fee is the story Dave is selling, while the card details are what he wants.
Moving from email to a website does not erase the email evidence. It creates another event with its own domains, accounts, timestamps, network observations and potential record holders.
Dave needs to benefit from the offence¶
Dave later attempts to use the captured card details for purchases. The email campaign, website submission and attempted transactions are separate events recorded from different observation points.
Their times, identifiers, accounts, addresses and device information can be compared, but they should not be joined merely because an investigator expects them to belong together. The preserved email explains the approach; web and hosting records may explain the collection route; card issuers and merchants may record the attempted use.
Dave needed more than a convincing From address. He needed a delivery route, a working website and a way to receive or use what he stole. Each requirement may create a line of enquiry.
Dave tries it again¶
Dave reuses the same page for another batch. He changes the subject, rotates part of the sending infrastructure and uses a different real address belonging to ParcelPost.
The changes may defeat a search based on one subject or server. Other features may still connect - or distinguish - the messages: destination URL, page content, recipient pattern, sending-service identifiers, timestamps, payment route and later card use.
Similar features do not prove one offender. They create propositions to test against provider, financial and device evidence.
Dave is pleased with himself¶
One recipient tells ParcelPost that its account has been hacked. Dave thinks the genuine address has directed the investigation towards an innocent company and away from him.
The address alone proves neither compromise nor innocence. ParcelPost's provider may confirm that no corresponding message was sent through the genuine account or its authorised systems. The recipient's trusted records may show where the email entered the delivery chain. The website and payment enquiries then move through their own record holders.
Spoofing created a false presentation. It did not rewrite the records held by every other system involved.
What Dave changed - and what he did not¶
The evidence may be incomplete. Authentication can fail for benign reasons; infrastructure may be shared; records may be unavailable; and a campaign link does not identify its operator. The point is narrower: forging one displayed field is not the same as controlling the genuine account or removing every other record needed to commit and benefit from the offence.
