SilentAir: review phone dependencies in account recovery
Account recovery can follow a different route from everyday login. Assess that dependency before travel or an incident makes recovery urgent.
Auf Portugiesisch lesenBy Pentesty
The observation and its limits
Enea reported signalling attacks attributed to SilentAir and observed SMS 2FA codes following interception for some targets. Its China-nexus assessment has low confidence; a connection to LIMINAL PANDA remains unconfirmed. The research does not establish compromise of every account using SMS.
For a company that does not operate mobile networks, the proposed work starts with access design in its own applications. Choose a small set of consequential accounts and describe how each can be recovered. The result should expose actual dependencies without attempting to reproduce attacks against telecommunications infrastructure or drawing conclusions about a particular carrier.
Draw the route back into the account
Consider an employee who normally uses an approved factor but loses access to the device while travelling. Who can recover the account? Which channel receives confirmation? Ask support to explain its current procedure, including exceptions for urgent requests, contractors and people who do not have corporate equipment. Work from the procedure actually available today.
Place ordinary login, factor replacement and complete recovery side by side. Mark where the same number reappears. This diagram supports a concrete decision: remove a dependency, provide a previously enrolled alternative or accept a time-limited exception. A statement that the company has MFA does not answer how those different routes work.
Exercise an alternative before it is needed
Propose an exercise using a synthetic account with support participating. Suspend only the agreed test factor and follow the documented alternative procedure. Observe whether the person regains the same authority and which independent confirmations were required. Do not use employee numbers or actual privileged accounts as test material, and agree on a stopping condition beforehand.
Assess the experience of someone who cannot use the old channel. If the procedure works only when a colleague improvises an approval, the alternative is not ready for predictable use. Turn the difficulty into a product or support decision, with clear instructions for the user and an accessible way to obtain help without restoring the unexamined route.
Prevent an exception from rebuilding the dependency
Imagine administrators have moved to another factor, while a secondary portal retains telephone recovery as its automatic fallback. The review should look for that return path, including approved third-party applications. Ask each owner to show the current configuration and explain what happens when a user requests replacement of an authentication factor.
Treat a role change as another scenario. Someone leaves the finance team but keeps the corporate number: which earlier privileges could still be recovered through that channel? This connects telephony, identity and permission removal. The exercise should test the consequence of a role change rather than relying only on the employee directory to describe current authority.
Prepare a response proportionate to the evidence
A delivery problem alone does not identify espionage or account compromise. Support should preserve the report and route it according to internal criteria. The identity team can assess changes and access in corporate applications; mobile-network questions require the appropriate carrier contact and evidence that the company itself may not possess or be able to interpret.
For an executive decision, present accounts with phone-dependent recovery, alternatives actually exercised and services still lacking an approved route. Explain the operational effect of withdrawing an option before doing so. The objective is to reduce an identified dependency through a usable transition, so future urgency does not quietly return the organization to the same starting point.
Frequently asked questions
Does this analysis propose testing the carrier network?
No. The proposed scope is application access and support within the organization, using synthetic accounts and factors covered by prior authorization.
Does replacing the login factor complete the review?
Check factor replacement, recovery and support exceptions as well. The decision should cover every route through which someone can regain account access.
How should accounts be prioritized?
Start with the consequences of incorrect recovery and the difficulty of operating without access. Include business-process owners when choosing a sample that can be justified.
Does a delayed message prove an attack?
Do not assign a cause to that signal alone. Preserve context and follow investigation criteria, separating the user’s observation from conclusions about the account or the network.
Sources and references
Original Pentesty analysis, published November 12, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.