FaceStealer: who approves a fix requested in a meeting?
A familiar meeting can create pressure to fix a problem quickly. Define who approves computer changes and how to verify the request through an independent path.
Ler em portuguêsBy Pentesty
The public account and its limits
In a November 12, 2026 statement, the DOJ attributes FaceStealer to North Korean operators: contact accounts, recorded or manipulated video and a fabricated audio failure are used to induce malware installation. The agency announces an infrastructure seizure. This is the authorities’ account; it does not establish a particular company’s compromise or a conviction of those involved.
For a business, the question is who can authorize a device change. Joining a conversation and approving installation, command execution or access are separate decisions. The following analysis proposes a process exercise without reproducing malware or relying on how participants look or sound. Its focus is an observable approval path.
Provide a practical exit from call pressure
Choose a support channel that employees already know how to locate outside the conversation. Document how to open a ticket, identify the device and request an alternative way to continue the activity. The person attending the meeting should not be the sole source of the address or number used to verify the request.
In an authorized exercise, simulate an update request intended to fix audio. Observe whether the employee can pause the change, contact support and resume work through an approved alternative. Assess the time and clarity of that path. If the only option requires abandoning an important negotiation, review the process with the business team.
Make approval identify the actual change
The ticket should identify the requested package or configuration, approved source, authorizing person and destination device. Ask support to check those details through its own tools. A product name written in a chat should not serve as the exercise’s approval criterion. The team needs a way to explain what it has checked.
Agree beforehand on how refusals and exceptions will be recorded. For an approved change, retain the ticket identifier and evidence of execution through the approved mechanism. For an attempt outside that process, check the signal and its accountable owner. Test on a laboratory device using a harmless file within an agreed window.
If someone already followed the instruction
Plan a response connecting support, the device and the identities used. Request timestamps, identifiers and context through a secure channel; avoid asking the employee to repeat the command to explain the event. The response owner should decide on authorized containment and preserve necessary records before making changes that could erase them.
Separate questions about software execution from questions about session authorization. The analysis of meeting invitations and device codes examines the latter path. For this exercise, establish which test resources became reachable through the device and its accounts, documenting the limits of the review and who will address any unresolved finding.
Accept the process through reproducible observation
Keep the proposed scenario, support decisions, device outcome and alternative used to continue the activity. Record what the team could not observe. A completed test should identify who receives the alert, who may approve the change and who decides when the device can return to normal work. Give each handover an accountable owner.
If the review identifies exposed credentials, route that decision to the identity owner. The discussion of credential revocation helps define a separate access check. Repeat the exercise after correcting support obstacles and compare outcomes. Assess evidence from the process rather than relying only on whether people remember a training message.
Frequently asked questions
Should verification use the same chat?
Define a previously known channel available outside the conversation. In the exercise, ask support to verify the request through its own references and tools.
How can the process be tested without malware?
Use a harmless file on a laboratory device with an agreed scope and window. Observe the support decision, approval and expected outcome on the device.
What evidence should accompany an exception?
Record the concrete change, justification, approving owner and destination device. Agree on how to check the outcome and close the exception.
How should the response after execution be assessed?
Correlate support, device and identity records. Document containment decisions, preserved evidence and questions that remain unanswered after the review.
Sources and references
Original Pentesty analysis, published November 13, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.