Russian Smishing Ops: Fake Support Texts Targeting Messaging Credentials
Just caught the latest report from the Security Service of Ukraine (SSU) and the FBI regarding a long-running campaign by Russian intelligence. It looks like they are relying on good old-fashioned social engineering—specifically Smishing—to breach messaging accounts of government and military personnel.
The attackers are posing as technical support to trick targets into handing over credentials. Since the goal is accessing messaging apps (likely Signal or Telegram), the pivot to lateral movement is a significant concern.
The Vector
This isn't a zero-day; it's trust exploitation. We're looking at:
- Spoofed SMS: Messages appearing to come from official support lines.
- Credential Harvesting: Phishing pages mimicking login portals to capture 2FA codes.
Detection Logic
If you are pulling mobile proxy logs or gateway data, you might want to hunt for indicators of these "support" scams. Here is a basic Python snippet to flag potential lookalike domains often used in these kits:
import re
def detect_suspicious_url(url):
# Look for 'support' or 'recover' mixed with suspicious TLDs
pattern = r'(support|secure|auth|recover)-(verify|login|account)\.(top|xyz|online|club)'
if re.search(pattern, url):
return True
return False
# Example log check
log_url = "http://signal-support-verify.top/login"
if detect_suspicious_url(log_url):
print(f"[ALERT] Suspicious phishing infrastructure detected: {log_url}")
Mitigation
Beyond standard awareness training, are you guys enforcing Mobile Threat Defense (MTD) solutions on your fleets? I'm curious if anyone has successfully blocked these specific SMS gateways at the network level without cutting off legit comms.
We started deploying an MTD solution that scans installed profiles and certificates. These fake support pages often try to push a malicious config profile to bypass MDM or install a root CA. Blocking the install of unsigned profiles on non-supervised devices is a nightmare though.
This reinforces why we need to kill SMS-based 2FA for high-value targets. We moved our executives to FIDO2 hardware keys. It makes the credential theft useless if they don't have the physical key, even if they get the password.
From a red team perspective, the success rate on 'support' smishing is terrifyingly high compared to standard phishing. The urgency of 'your account will be deleted' bypasses critical thinking. The Python snippet is handy, but don't forget to regex for punycode/homoglyphs too.
Great insights. On the defensive side, we found immediate success by automating the ingestion of IoCs from these reports into our Secure Web Gateway. This blocks the malicious landing pages before users can even click. For quick triage of suspicious URLs found in texts, we often run a check against VirusTotal using Python:
import requests
params = {'apikey': 'YOUR_API_KEY', 'url': 'https://suspicious-link.com'}
response = requests.post('https://www.virustotal.com/vtapi/v2/url/scan', data=params)
print(response.())
Solid insights. Since these attacks heavily rely on pushing malicious configuration profiles, we added a specific detection rule in our SIEM. This KQL query alerts us immediately if a device installs a profile outside of our standard deployment window, allowing us to isolate the device before the attackers can pivot to internal resources.
DeviceProfileEvents
| where ActionType contains "Profile Added"
| where Timestamp > ago(1h)
| project DeviceName, ProfileName, Timestamp
It’s a small safety net that catches what IoCs might miss initially.
Great insights. Since the endgame often involves exfiltrating chat history for lateral movement, we tuned our EDR to monitor for unauthorized access to local messaging datastores. We focus on detecting non-native processes reading Signal or Telegram database files.
Here is a simple KQL query to flag suspicious reads from the Telegram directory: kusto DeviceFileEvents
| where FolderPath contains @"Telegram\tdata"
| where InitiatingProcessFileName != "Telegram.exe"
Building on CryptoKatie's point, if the profile slips through, checking for rogue root CAs is critical. On Windows endpoints, we run this PowerShell snippet to audit the local machine store for non-standard issuers that might be intercepting Signal traffic:
Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object { $_.Issuer -notmatch 'Microsoft' -and $_.Issuer -notmatch 'DigiCert' } | Select-Object Subject, Issuer, NotBefore
It helps catch the remnants of a successful profile drop even if the SIEM misses the initial install event.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access