The Browser Says You Are Infected: Four Checks for Fake Security Alerts

The warning fills the browser window. It uses familiar colours, claims the computer is infected and offers a number to call. Fake security alerts turn a routine web visit into a decision about who gets access to a business device. The immediate risk may not be the infection described on screen. It may be the person offering to fix it.

For an Australian business, this is more than a staff-awareness problem. It tests whether support can be verified independently and whether an employee can give an unapproved operator control of a device containing customer information.

The message is in the browser. The access is real.

A malicious page or advertisement can imitate security software, use urgent language and direct someone to a fake support number. Browser notifications can also deliver alarming messages after a user has allowed notifications from a site. An ordinary webpage claiming to have scanned the computer is not, by itself, reliable evidence of an infection.

The next step matters. The caller may be guided to install or open a legitimate remote-support tool. Legitimate software does not make the person using it trustworthy. Depending on the permissions granted, the operator may see files and applications, request credentials, change settings or pressure the employee into making a payment.

Customer exposure can follow even without a confirmed malware installation. A remote operator who can view an open customer system may see information already accessible to that employee. Seeing a working support connection proves that access was established, not that the session was authorised.

Four checks for fake security alerts

1. Verify the support route, not the screen design. Give staff an independently known IT contact and an easy way to find it. A number displayed in a warning or a sponsored search result is not independent verification. A genuine support request should be checked through the organisation’s established channel before access is granted.
2. Control which remote tools can run. Ask IT which support applications are approved, who can start a session and how unexpected tools are detected. Removing local administrator rights can limit some installations, but does not block every portable or user-level remote tool. Application controls and service configuration need to match the actual environment.
3. Make authorised sessions accountable. Require a verified support request, an identified operator and an understood scope. Check whether unattended access is enabled, how sessions are ended and what logs are retained. A tool appearing on an approved list does not mean every use of that tool is approved.
4. Practise the response to a mistaken connection. Staff should know how to contact IT promptly, including from another device. The business needs a response owner who can assess access, preserve evidence and decide whether credentials, sessions or affected devices need containment. Closing the original warning alone does not establish that remote access has stopped.

What evidence should the business owner ask for?

Request the approved-tool inventory, a sample authorised support record and evidence that unexpected remote-access software is detected or restricted. Ask how a session started outside the normal process would be investigated. This is a stronger assurance than being told that staff received a reminder or that antivirus is installed.

The controls have trade-offs. Overly restrictive rules can interrupt legitimate supplier support, while broad exceptions can leave an easy route around the policy. IT and the service owner should agree on a workable approval process, including urgent support, without making urgency itself proof of authority.

If somebody has already granted access

Escalate promptly through trusted IT contacts. Record what was shown, the claimed organisation, approximate times and any tools used. IT should assess the access and appropriate containment; avoid deleting evidence or assuming a clean scan settles whether information was viewed. If money or banking details were involved, contact the financial institution through its official channel as well. Reporting and notification obligations depend on the facts and applicable requirements.

How Xpansion can support your next step

Xpansion Technologies can help review managed IT and security controls, support-access processes and practical escalation arrangements. The goal is not simply to make warnings look less convincing. It is to stop an unverified warning becoming an authorised route into your business.

Sources

• ASD/ACSC: Learn how to spot scams, including remote-access scams
• US FTC: How to spot, avoid and report tech-support scams

This is practical guidance, not a report of a new incident. The US source supports the scam mechanism; it does not set Australian reporting obligations.