[Security News] Fake Support Texts Target Messaging Accounts (6.28)

Ukraine’s security service and the FBI linked a long-running credential-theft campaign to Russian intelligence, with government, military and civil-society…

Table of contents

1. Overview
2. Fake support messages put trusted accounts in the firing line
3. Government, military and civil-society users shared the risk
4. No disclosed CVE changes the patching calculus
5. Account defenses take priority over speculative attribution details
6. At a glance
7. FAQ
8. Sources

Fake Support Texts Target Messaging Accounts (6.28)

Overview

• The Security Service of Ukraine and the FBI reported a long-running Russian intelligence campaign aimed at stealing credentials for messaging accounts.
• The reported target set crossed national and professional lines, encompassing officials, military personnel, politicians and activists in Ukraine, Europe and the U.S.
• The supplied evidence identifies social engineering through fake support messages, but it names no CVE, vulnerable product version or software exploit.
• CISA, NIST, Microsoft and Google remain authoritative sources for advisories, CVE metadata, product updates and security research, though the supplied records contain no campaign-specific notice from them.

Fake support messages put trusted accounts in the firing line

The Security Service of Ukraine, known as the SSU, said it worked with the FBI to uncover a long-running credential-theft operation attributed to Russian intelligence services. The Hacker News reported the finding on June 27, within the June 28 coverage window used for this article. The campaign allegedly used messages posing as technical support to obtain access credentials for messaging accounts.

The reported victims included government officials, military personnel, politicians and activists. They were based in Ukraine, elsewhere in Europe and the U.S. That selection indicates an intelligence-collection objective rather than indiscriminate consumer fraud. Access to a messaging account can expose private conversations, contact networks and the identity of future targets without requiring an attacker to compromise an organization’s central systems.

The available source excerpt does not identify a vulnerable application, affected version or CVE. It also provides no CVSS score, PoC release or evidence that a software flaw enabled the intrusions. The confirmed defensive issue is therefore credential theft through social engineering. Organizations should prioritize phishing-resistant multifactor authentication, account-session reviews and independent verification of support requests.

▸ Credential-theft campaign deep dive

The operation’s reported use of fake support messages reflects a practical choice. Messaging services have become working directories for officials, soldiers, political staff and activists. Their accounts may reveal relationships and operational context even when individual conversations use encryption. An attacker who controls a legitimate account can also approach the victim’s contacts with an identity that those contacts already trust.

That trust changes the defensive problem. Conventional filtering can identify suspicious domains, attachments or mass-mail patterns. A targeted support message may contain none of those signals. It can instead pressure a recipient to disclose a verification code, approve a login or follow an account-recovery sequence. The supplied reporting does not specify which interaction the campaign used, so those examples describe common defensive scenarios rather than confirmed mechanics of this operation.

The joint involvement of the SSU and FBI indicates that the investigation crossed jurisdictions. The source places targets in Ukraine, Europe and the U.S., which would require evidence sharing between service providers and national authorities. Such investigations often depend on login records, account-recovery events and infrastructure links. The provided material does not disclose that evidence or explain the attribution method, however. Russian intelligence attribution should therefore be presented as the SSU’s official conclusion, supported by its work with the FBI, rather than as an independently reproduced technical finding.

The account-centric nature of the threat also affects incident response. A password reset alone may not remove an intruder if active sessions, recovery addresses, linked devices or application tokens remain valid. Defenders should revoke existing sessions, review newly enrolled devices and inspect recent changes to recovery settings. They should also preserve authentication logs before routine retention periods erase useful evidence.

Phishing-resistant authentication offers stronger protection than codes that users can relay. Hardware security keys and passkeys bind authentication to the legitimate service, reducing the value of a deceptive prompt. Where those options are unavailable, organizations can require a second employee to validate unusual support contacts and sensitive account changes through a known channel.

The source excerpt describes the attacks as systematic and long-running but gives no start date, victim count or success rate. Those omissions prevent a numerical estimate of exposure. They also make it impossible to determine whether the campaign remains active at the same level. The prudent response is targeted account review for people whose work or relationships match the disclosed victim profile, not a claim that every messaging user faces the same risk.

Government, military and civil-society users shared the risk

The reported targeting extended beyond a single agency or country. The Hacker News said the SSU and FBI investigation covered government officials, military personnel, politicians and activists across Ukraine, Europe and the U.S. Those groups possess different forms of sensitive information, but their communications often overlap during wartime, diplomacy, advocacy and public-policy work.

That overlap can make a single account valuable for more than its message history. Contact lists may map relationships among institutions. Group memberships may identify projects or operational teams. A compromised account may also provide a credible route to additional targets. The supplied evidence confirms the breadth of the target categories, but it does not state that every targeted account was successfully breached.

Organizations should distinguish targeting from compromise when assessing their exposure. Receipt of a deceptive message shows attempted access, while unfamiliar sessions, changed recovery settings or unauthorized messages provide stronger signs of account takeover. Response teams should record those categories separately. Doing so supports a more accurate assessment and avoids treating every suspicious text as proof of intrusion.

▸ Targeting pattern deep dive

The mixture of public officials, military users and activists is consistent with an effort to collect information from both formal institutions and the people around them. Government systems may receive centralized monitoring, while personal messaging accounts can fall outside enterprise controls. Political staff, advisers and civil-society contacts may also discuss the same events through less-managed devices or accounts.

This creates an uneven security boundary. An organization may protect email with managed devices, conditional-access rules and centralized logging while leaving messaging applications under individual control. Attackers can exploit that difference by approaching the person rather than the institution. The source does not say whether targets used personal or managed accounts, but the broad victim profile makes consistent account governance an important defensive question.

Risk also varies by role. Military personnel may expose operational relationships or schedules. Officials and politicians may hold policy discussions or contact details. Activists may connect journalists, witnesses and local communities. These examples explain why the named categories could attract intelligence collection; they are not claims that the reported campaign obtained any particular document or conversation.

A useful review begins with identity rather than software inventory. Security teams can identify personnel who belong to the disclosed target groups, determine which messaging services they use for work and establish whether those accounts support phishing-resistant authentication. They can then check session histories and recovery changes where logs are available. This approach is more relevant than scanning for a nonexistent campaign CVE.

Training should address the authority claimed by a fake support contact. Users may comply because the message appears to solve an urgent account problem. Policies can reduce that pressure by stating that legitimate support staff will not request passwords or one-time codes. Internal support teams should use a recognizable process, and employees should have a separate channel for validating unexpected contacts.

Cross-border targeting adds another complication: language, time zone and local service practices can make a fraudulent request appear plausible. A message tailored to the recipient’s role may evade generic awareness material. Short exercises built around account recovery, new-device approval and support impersonation can test the decisions that matter without reproducing attack payloads.

The reporting does not provide a total number of targets, affected organizations or confirmed account takeovers. It also does not divide activity by country or profession. Those gaps rule out claims about which group suffered the greatest impact. The available evidence supports a broad risk pattern and a focused defensive response, but not a quantified damage assessment.

No disclosed CVE changes the patching calculus

The supplied record contains no CVE identifier tied to the campaign. It lists no affected operating system, application release or device family. It also offers no CVSS 3.1 score, vendor patch, workaround or PoC. Those absences matter because they place this incident outside the usual vulnerability-management workflow.

NIST’s National Vulnerability Database provides CVE records and severity metadata, while CISA publishes advisories and mitigation guidance. Microsoft maintains its Security Update Guide, and Google publishes product-security and vulnerability-disclosure research. In the material supplied for June 28, however, those entries are general reference pages rather than campaign-specific findings. They do not corroborate a software vulnerability behind the reported credential theft.

Security teams should not create a patch requirement where the evidence supports none. The immediate controls are identity-focused: require stronger authentication, revoke suspicious sessions, protect recovery channels and monitor for messages sent from compromised accounts. Normal patching should continue, but the article’s evidence does not justify linking any particular update to this operation.

▸ Evidence and CVE status deep dive

A CVE identifies a publicly disclosed vulnerability in software or hardware. A CVSS score then helps organizations estimate technical severity through factors such as attack complexity, privileges and impact. Neither mechanism applies automatically to deception that persuades a user to surrender an account credential. The absence of a CVE is therefore not evidence that the campaign is harmless; it means the known attack path is not described as a product flaw.

This distinction affects ownership. Vulnerability-management teams usually inventory affected versions, compare severity scores and deploy patches. Identity and incident-response teams instead examine authentication events, device enrollment, session persistence and recovery changes. When a campaign relies on support impersonation, the second workflow carries the immediate burden.

The official resources in the supplied data still have operational value. CISA advisories can establish whether a related weakness later receives federal mitigation guidance. NIST can supply standardized CVE metadata if researchers identify a product flaw. Microsoft’s Update Guide can confirm affected products and fixes within its ecosystem. Google’s security publications can document product changes or research. As of the supplied coverage set, none contributes a campaign-specific CVE or technical advisory.

That evidence boundary prevents several unsupported conclusions. There is no basis here to call the incident a 0-day. There is no disclosed remote code execution(RCE), privilege escalation(LPE), server-side request forgery(SSRF), cross-site scripting(XSS) or SQL injection(SQLi). There is also no evidence of public exploit code or active exploitation of a software defect. Active credential theft and active exploitation are different claims.

Patch priority should therefore remain tied to each organization’s existing exposure and authoritative vendor notices. Teams should avoid delaying critical updates while investigating this campaign, but they should not tell administrators that an unspecified patch will stop fake support texts. Technical controls must address the path actually described by the source.

Future reporting could change that assessment. Investigators might disclose that the actors combined social engineering with a product vulnerability, or a vendor could publish an advisory linked to the same operation. If that occurs, defenders would need the exact CVE, affected versions, severity, exploitation status and mitigation instructions. Until then, the responsible description is narrower: a reported intelligence campaign used deceptive support messages to pursue messaging credentials.

Account defenses take priority over speculative attribution details

The SSU attributed the campaign to Russian intelligence services and said the FBI participated in uncovering it. That is the strongest attribution statement in the supplied material. The excerpt does not name a specific intelligence agency, threat group or malware family. It also contains no infrastructure indicators, forensic timeline or public statement from the FBI.

Those limits do not erase the reported finding, but they define how confidently each part can be stated. The investigation and attribution are official SSU claims. The cross-border target categories and fake-support method come from The Hacker News account of that announcement. Technical details beyond those points remain undisclosed in the provided evidence.

For defenders, the response does not depend on resolving every attribution question. The same account controls reduce exposure to state-linked operators, criminal groups and ordinary fraud. Security teams can act on the observed method while reserving judgment on details that investigators have not published.

▸ Attribution and response deep dive

Cyber attribution usually combines multiple evidence types. Investigators may compare infrastructure, operating patterns, targeting, account activity and information available only to service providers or governments. The supplied source excerpt does not reveal which indicators supported the SSU’s conclusion. Independent readers therefore cannot reproduce the attribution from the published details alone.

The FBI’s reported involvement gives the investigation an international law-enforcement dimension, but the excerpt stops short of quoting the bureau or describing its contribution. It would be inaccurate to convert joint investigative work into a separate FBI attribution statement. Careful reporting preserves that distinction while recognizing that the SSU publicly connected the operation to Russian intelligence.

Attribution uncertainty and defensive certainty can coexist. An organization does not need to identify the operator before revoking an unauthorized session. It does not need a threat-group label before protecting recovery channels. These actions address observable account risk and carry little downside when applied through established incident-response procedures.

The response should begin with high-value users. Personnel in the reported target categories merit enhanced authentication and logging because their relationships may be valuable even when their own messages contain little classified material. Administrators should also review service accounts or shared communication channels that rely on personal recovery methods.

Detection can focus on anomalies rather than message content alone. New logins from unfamiliar devices, abrupt changes to recovery information and unexpected outbound messages can indicate account takeover. Each platform exposes different telemetry, and the source does not identify the services involved. Organizations must therefore adapt checks to the accounts they actually manage instead of assuming a single universal indicator.

Communications planning matters after a suspected takeover. Contacts should receive a warning through a separate trusted channel because the compromised account itself may be under adversary control. Investigators should preserve logs and message records under applicable legal and privacy rules. Public statements should separate confirmed unauthorized access from attempted targeting and avoid assigning a victim count without evidence.

The next meaningful disclosures would include the campaign’s operating period, number of confirmed compromises, affected messaging services and attribution evidence. Product vendors could also report whether attackers abused legitimate account-recovery features or exploited a technical defect. Until such information appears, defenders gain more from closing identity-control gaps than from assigning an unsupported name to the actor’s tooling.

▸ More — additional context and sources

Ukraine Says Russian Intelligence Used Fake Support Texts to Steal Messaging Credentials

Reported by feeds.feedburner.com. The Security Service of Ukraine (SSU) said it, together with the U.S.

At a glance

Fact	Publisher	Source
SSU and the FBI uncovered a long-running campaign attributed to Russian intelligence services.	The Hacker News	thehackernews.com
Reported targets included officials, military personnel, politicians and activists.	The Hacker News	thehackernews.com
CISA publishes official cybersecurity advisories and mitigation guidance.	CISA	cisa.gov
NVD maintains CVE records and associated severity metadata.	NIST	nvd.nist.gov
Microsoft’s Update Guide provides product vulnerability and security-update information.	Microsoft	msrc.microsoft.com
Google publishes security research, product-security and vulnerability-disclosure posts.	Google	security.googleblog.com

FAQ

Q1. What attack method does the reporting actually confirm?

A. The Hacker News reported that the SSU and FBI uncovered fake support messages intended to steal messaging credentials. The supplied evidence does not identify malware, a malicious attachment or a software vulnerability as the access method.

Q2. Why can this campaign matter even without a CVE?

A. Account takeover can expose conversations, contacts and trusted identities without exploiting software. NIST’s CVE records and CVSS metadata apply to disclosed product weaknesses, while this evidence points to social engineering and credential theft.

Q3. Which control offers the strongest immediate reduction in risk?

A. Phishing-resistant multifactor authentication, such as passkeys or hardware security keys, directly reduces the usefulness of stolen passwords and relayed codes. Organizations should pair it with session revocation and recovery-setting reviews for the four reported target groups.

Q4. How should readers interpret the Russian intelligence attribution?

A. The attribution is an official SSU conclusion from an investigation conducted with the FBI, as reported by The Hacker News. The supplied material provides no public forensic indicators or separate FBI quotation, so the underlying technical case cannot be independently assessed here.

Q5. What later evidence could change the response priority?

A. A CISA advisory, NIST CVE record, Microsoft update or Google disclosure could establish a product-specific issue. Defenders should watch for an exact CVE, affected versions, CVSS 3.1 score, exploitation status and vendor mitigation before assigning campaign-driven patch urgency.

Sources

1. Ukraine Says Russian Intelligence Used Fake Support Texts to Steal Messaging Credentials - feeds.feedburner.com
2. CISA Cybersecurity Advisories - CISA
3. National Vulnerability Database - NIST
4. Microsoft Security Response Center - Microsoft
5. Google Online Security Blog - Google

Last updated: 2026-06-28T22:53:07.297Z