A familiar supplier still needs a verified request

A supplier can be real and its message dangerous. In its October 28 threat report, ESET describes attackers using a compromised Israeli IT vendor in August to send targeted phishing emails to organizations in Israel and the United States. If successful, the malicious attachment placed ScreenConnect, a remote-management tool, on the recipient's system and ran it. ESET report, page 13 (external source, opens in a new tab)

For a customer, years of legitimate messages and useful support can make a new file seem routine. That history is a reason to recognize the relationship; it cannot establish who is behind this particular request. The difficulty becomes clearer when the customer tries to check. A question sent back through the same compromised channel may simply give the attacker another opportunity to reassure the recipient.

Suppose an employee receives an unexpected attachment from a supplier and replies, asking whether it should be opened. If an attacker controls that mailbox, a reassuring reply supplies no independent evidence. Calling an established contact on a number already held by the business gives the check a separate route. The conversation should identify the particular message, file, and requested action, rather than settle for confirmation that the companies work together. NIST's phishing guidance (external source, opens in a new tab) similarly recommends verifying requests through known contact information, rather than contact details supplied in the message.

The ScreenConnect detail extends the same problem to the software. Recognizing a remote-support product does not establish why it has arrived or who intends to use it. In the reported attack, its presence followed a malicious attachment. A supplier's assurance also cannot establish that a file is technically safe, so the verification call should not become a reason to bypass the organization's checks on attachments and software. The request and the file each need examination.

The useful answer may be that the supplier did not send the file. That answer needs to reach the people handling security on both sides, so they can investigate the message and establish whether others received it. Verification then becomes an opportunity to alert the supplier to a possible compromise. Arrange the contact route while the relationship is running normally, when both sides can check whom to reach without relying on the message they are trying to investigate.