An employee gets a Microsoft Teams call from IT. The technician knows the right language, opens a familiar remote-support tool, and asks for control of the screen. Nothing arrives as an attachment. There is no misspelled domain to spot. Every piece of software on the screen may be legitimate.

The technician is not.

That distinction now matters more than most of the warning signs in a standard security-awareness course. Attackers are getting better at borrowing things we already trust: the collaboration platform the company uses, the support tools IT has installed, a software vendor’s website, and personal information that only a legitimate organization should know.

The useful question is no longer only, “Does this look real?” It is, “Can I verify this request somewhere the requester does not control?”

The support call can be the attack

On September 2, Microsoft described an active campaign in which attackers used external Microsoft Teams accounts to impersonate IT and helpdesk staff. They persuaded employees to approve screen control during a Teams session or to open Quick Assist and provide a connection code.

Once connected, the attackers used PowerShell and Windows Installer to deploy a persistent backdoor. From there they could capture screenshots, map the company’s Active Directory environment, and move toward high-value systems such as domain controllers. The attack relied heavily on legitimate Microsoft and remote-management tools, which helped it blend into ordinary administrative work. Microsoft’s account of the campaign is worth reading if you run an internal or outsourced help desk.

Nothing was exploited during the initial contact. The employee was persuaded to authorize the access.

That is why having the right application on the screen proves very little. A real technician and an attacker can both use Teams, Quick Assist, ScreenConnect, or another recognized support product. The control is the procedure around the tool: who may initiate a session, how the employee verifies that person, and whether the request corresponds to a ticket the employee can see.

For an unexpected support request, end the conversation and call the help desk using the number in your company directory or support portal. Do not use a number or link supplied by the person making the request. A legitimate technician will expect the check.

A polished download page proves nothing

The day before that Teams report, Microsoft documented another active campaign using high-fidelity copies of legitimate software-download sites. A person searching for a familiar application could land on a convincing vendor page, select an ordinary-looking download button, and receive a malicious installer.

The installer established persistence, attempted to weaken security controls, and contacted attacker-operated infrastructure. Some files were regenerated for each download, which made simple file-hash blocklists less useful. Microsoft observed the campaign primarily among China-based operations of multinational organizations and Chinese-speaking users, but the control failure is universal: a page that resembles a vendor is not evidence that the installer came from that vendor. Microsoft’s technical analysis includes examples of the look-alike sites and delivery chain.

Employees should not have to determine whether a download page is authentic. Business software should come from a managed application portal, an approved vendor bookmark, or an IT request. Where staff can install software themselves, the written rule should be simple: do not install a business application from an advertisement, a search result, or a link in an unsolicited message.

This is not an argument that nobody should download software from the web. It is an argument that a search engine should not be part of your company’s software supply chain.

A readable email may not be what the filter read

On September 3, Microsoft published research into a high-volume phishing campaign that placed invisible Unicode characters inside financial words. A recipient still saw a normal word such as “funding.” A filter looking at the underlying characters could see that word split into unfamiliar pieces.

Microsoft’s telemetry showed the technique jumping from roughly 21,000 signature hits on February 8 to more than 1.3 million the following day. During the campaign’s high-volume period, daily counts reached more than two million. The invisible characters were only one part of the operation; disposable finance-themed domains and a legitimate email-marketing platform helped the messages resemble ordinary bulk mail.

This does not mean the filters failed completely. Microsoft says its layered protections flagged more than 99 percent of the messages using other signals. It does mean that attackers continually test how mail systems parse a message, and no single filter or product should be treated as conclusive. The research also shows how a technique first discussed in AI security can be repurposed for conventional phishing.

For an employee, the technical detail is less important than the conclusion. A message reaching the inbox does not make it safe. Slow down when any message asks you to sign in unexpectedly, approve an MFA prompt, open an unfamiliar document, install software, change payment information, share sensitive data, or grant remote access.

Correct personal information is not identity proof

Attackers do not have to guess every detail in a convincing request. Much of the information they need may already have been breached, purchased, or collected from public sources.

This week, the FBI opened an investigation into a dark-web service claiming to offer more than 153 million scans of US and Canadian driver’s licenses. Security reporter Brian Krebs found his own license in the service and traced several records to dates on which their owners had presented identification to businesses using third-party verification technology. The reported source and the service’s total record count remain under investigation, so the number should not be treated as a confirmed victim count. Krebs’s original report documents what is known and what is not.

Separately, a Thomson Reuters business disclosed that an unauthorized party obtained files associated with its C-Track court-management platform in March. The incident affected courts in 11 states, the US Virgin Islands, and Ontario, and some files contained names and other personal information, according to reporting by Reuters.

The practical consequence is larger than identity theft. Stolen records give attackers the material to sound informed. Someone may know an employee’s full name, title, manager, address, supplier relationship, or recent transaction and still be a stranger.

Security questions based on facts are especially weak for this reason. A date of birth, driver’s-license number, previous address, or last four digits of an identifier are data, not secrets. Help desks, payroll teams, and finance staff should not use them as the only proof that a caller is who they claim to be.

Verify the request, not its appearance

Spelling errors, unusual sender addresses, and unexpected attachments remain useful warning signs. They are just not a sufficient trust test. Modern attacks can use professional writing, accurate personal details, real platforms, and legitimate administration tools.

Before taking a sensitive action, ask five questions:

Was I expecting this? An unplanned support call or MFA prompt deserves a stop, even when the name on it is familiar.
Does it follow our normal process? Real urgency does not require an employee to abandon the process designed for urgent events.
Can I verify it through a separate channel? Call a number already in the directory, open the known support portal, or contact the person directly in a new conversation.
What authority am I being asked to give away? Credentials, screen control, software installation, money, and sensitive information all need a higher standard than a routine question.
Is the requester choosing every verification method? If the same person supplies the message, the link, the phone number, and the proof, nothing has been independently verified.

The principle is the same one we recommend for payment changes in the wire transfer that almost happened and for executive calls in your CFO’s voice is now an attack surface: move the decision to a channel the attacker did not arrive through.

Three rules worth putting in writing

Most employees do not need the technical details of every campaign. They need clear authority to stop and three rules they can remember.

Never grant unexpected remote access. If IT contacts you without an open ticket or scheduled appointment, verify the technician through the normal support process before allowing a connection. This applies even when the call comes through Teams and the remote-support application is one the company uses.

Never run commands supplied by an unfamiliar site or unsolicited contact. A website does not need you to open PowerShell, Windows Terminal, Run, or a command prompt to prove you are human, install a routine update, or repair an ordinary browser problem. Stop and call IT.

Never let familiarity substitute for verification. A company logo, known voice, recognized platform, correct customer detail, or polished message can all be copied or borrowed. Verify the person and the request independently when the action involves access, credentials, money, software, or sensitive data.

Make the safe action the easy action

Telling employees to verify will not work if verification means searching for a phone number, guessing who owns the issue, or worrying that they will be blamed for slowing down a senior executive. The business has to provide the path.

Publish one helpdesk number and one support portal. Distribute software through an approved catalog. Require callbacks to numbers already on file for financial changes. Replace knowledge questions with authenticated approval or manager confirmation. Make it explicit that nobody will be penalized for pausing a sensitive request to verify it.

Email filtering, endpoint protection, MFA, managed software, and security monitoring still matter. The recent campaigns are not evidence that technology has become useless; they are evidence that attackers will try to persuade a person to authorize what the technology would otherwise block.

When the request involves money, credentials, software, remote access, or sensitive information, appearance is not proof. Verify before you trust.

If your remote-support, software-installation, or identity-verification process depends on an employee deciding whether something looks legitimate, we can help replace that judgment call with a process your staff can actually follow. Get in touch and we will start with the request that carries the most authority.