Prevent fake IT support requests from becoming account compromises by verifying each request through a contact route your organization already trusts, approving remote access only for a defined task, and keeping administrative accounts separate from everyday work. If someone has already connected, end the session, contact your security lead, preserve relevant records, and investigate affected accounts and systems before restoring access.
What does the reported attack mean for Atlanta businesses?
The Hacker News reported on November 2, 2026, that attackers posed as IT support through Microsoft Teams and persuaded employees to grant remote control of their PCs. The report says the attackers then abused insecure Active Directory Certificate Services settings to obtain login certificates for privileged accounts, including a domain controller account.
Microsoft investigated two intrusions, according to the report; one resulted in company data being stolen. The practical lesson for Atlanta businesses is that a request can seem familiar and technically plausible without being authentic. A chat account, meeting invitation, or confident explanation is not an identity check.
Employees, help desk staff, administrators, and business owners each have a part in preventing an escalation. A compromised workstation may provide a route toward more powerful accounts if verification, access controls, and escalation procedures do not hold.
Microsoft investigated two intrusions, according to the report.
Decide in advance who can authorize remote support, how employees confirm that person's identity, and which accounts may be used for sensitive work. Write the process so it applies to routine requests as well as urgent ones.
The takeaway: treat an unexpected request for remote control or elevated access as unverified until independently confirmed.
How should employees verify an IT support request?
Do not use only the phone number, chat account, meeting invitation, or link supplied in the request to verify it. Instead, use a known service desk number, an established support portal, or an internal directory your organization already trusts. If the request arrives in Teams, contact support separately through that known route.
Ask for a ticket or incident reference, but do not treat the number as proof. Confirm that the ticket exists in the trusted system, that the issue matches the employee's experience, and that the proposed work is expected. If the details do not line up, stop and notify the designated IT contact.
Set a clear rule: employees do not install remote-control tools, approve connection prompts, share one-time codes, or grant screen control in response to an unsolicited request. Legitimate urgent work still follows the verification process. Urgency can speed up escalation; it does not replace identity checks.
Give employees a short response they can use without making a technical judgment: "I'll contact support through our normal channel and confirm this request before connecting." Rehearse the process so people know whom to contact and what to do if the usual contact is unavailable.
The takeaway: verify through a trusted channel the requester did not supply.
How can we limit remote support access?
Connect each remote session to a defined work purpose, an identified user or device, and an approved request. The employee should know who is connecting and why. Where the support process allows it, have the employee remain present, observe the work, and end the session once the task is complete.
Keep everyday troubleshooting separate from privileged administration. A support technician working on a user's computer should not automatically need an account with broad administrative rights. Use distinct administrative identities, grant only the permissions required for the task, and document approval when access reaches sensitive systems.
Review support tools and accounts as part of account lifecycle management. Remove access that is no longer needed, close temporary exceptions when their purpose ends, and revisit permissions after role changes or provider transitions. Assign an owner to each account and tool so that access has a clear business purpose.
Use a repeatable approval sequence for remote support:
- Confirm the requester and the work through an established channel independent of the incoming contact.
- Approve access only to the named user, device, and task; confirm whether elevated privileges are actually required.
- Stay present during the session when practical, observe the actions, and end access when the approved task is complete.
- Record the ticket, approval, systems accessed, and any exception that needs follow-up.
Atlanta organizations may also need to coordinate IT access with facilities teams and building-system owners. A workstation, door controller, and camera platform can have different administrators and operational consequences. Define who may authorize access to each system, and make sure the support process covers systems beyond standard office computers when they are in scope.
GDS Technology's episode on ownership of building-system accounts discusses account inventories, accountability, and access reviews after organizational or system changes.
The takeaway: make remote support scoped, approved, observable, and time-limited where practical.
How do we protect privileged accounts and certificate services?
Privileged accounts can change systems, manage users, or access sensitive information. Keep them separate from routine email and browsing, protect them with strong authentication, and restrict who can use them. Employees should not need administrative rights for ordinary tasks such as reading email or joining a meeting.
Maintain an inventory of administrative identities, their owners, their purposes, and the systems they can reach. Review it when employees change roles, vendors change, or systems are replaced. Remove dormant or unnecessary accounts, and investigate unfamiliar identities or permissions instead of assuming they are still required.
In environments using Active Directory Certificate Services, include certificate services in access and configuration reviews. Certificates can support authentication, so review who can request them, which identities they may represent, and how issuance is monitored. Assign clear responsibility for those settings and changes.
Make sensitive activity visible with available audit records and alerts. Review administrative account creation, privilege changes, unusual authentication, and certificate issuance. Preserve relevant records during an investigation so responders can reconstruct events and determine whether access was created or reused.
GDS Technology's cybersecurity work can include account inventories, access reviews, authentication configuration, permissions reviews, lifecycle procedures, and change documentation. Define the scope around the organization's systems and operating needs.
The takeaway: manage administrator accounts and certificate issuance as controlled business dependencies.
What should an Atlanta business do after a suspicious support session?
If an employee has granted remote control to an unverified person, disconnect the session and stop interacting with the caller. Contact the established IT or security lead through a trusted route. Do not rely on the suspicious caller to explain the event or direct the response.
Preserve the affected device and relevant records. Note the time, account involved, contact method, software used, actions observed, and any files or credentials shared. Avoid deleting tools or logs before responders determine what evidence they need. If privileged credentials may be exposed, follow the incident plan to disable or reset them.
Assess the scope before returning the device or account to normal use. Review authentication history, remote-access records, privilege changes, and relevant system logs. If Active Directory Certificate Services is in use, include certificate issuance and configuration in the investigation. A password reset alone may not address every form of access that was created.
Georgia's data-breach notification law and applicable industry obligations may affect how an organization evaluates an incident. Whether notification is required depends on the circumstances and the organization's obligations. Involve counsel and the appropriate decision-makers rather than drawing conclusions from an initial alert.
Ashlee, a commercial real estate client, described GDS Technology's support this way: "GDS Technology answers every question we throw at them and actually follows through to solve it. You get real answers, not deflection, and the problem gets fixed, not just talked about. They make it easy to bring them anything and walk away with a result." Clear answers and follow-through matter when a suspicious access event needs investigation, documentation, and coordinated next steps.
For organizations reviewing their support model, GDS Technology provides cybersecurity services and IT help desk support. The goal is practical coordination around the organization's systems and operating needs, not a promise that risk can be eliminated.
The takeaway: contain access, preserve evidence, and assess identity and system changes before resolving the incident.
Frequently Asked Questions
Should an employee ever approve an unsolicited remote support request?
No. Employees should pause and verify the request through a known support channel before approving remote control, installing a tool, or sharing a code. A familiar name, urgent explanation, or recognizable collaboration app does not prove identity. If the work is legitimate, support can confirm it through the organization's established process.
Why are privileged accounts at risk in fake support incidents?
Privileged accounts can make changes beyond a normal user's permissions. If an attacker gains access to one, the potential reach may include additional accounts or sensitive systems. Keep administrative identities separate, limit their permissions, require strong authentication, and review activity such as privilege changes and certificate issuance.
What if someone already gave a caller remote control?
End the session, contact the organization's IT or security lead through a trusted route, and preserve relevant details and logs. Treat exposed credentials as potentially compromised and follow the incident plan for disabling or resetting them. Investigate account activity and system changes before restoring normal access or assuming a password reset was sufficient.
Can a ticket number prove that an IT support request is legitimate?
A ticket number is useful context, but it is not proof by itself. Confirm that the ticket exists in the organization's trusted system and that its issue, requester, and planned work match the current request. When anything differs, stop and verify through a separate contact method already known to the employee.
Follow GDS Technology on Facebook, and subscribe on YouTube for new videos.
