APT29's 'Tech Support' Pivot: Signal Recovery Key Harvesting
Just caught the SSU/FBI report on the recent campaign by Russian intel services targeting high-value individuals. This isn't your average credential stuffing; they are actively using smishing (SMS phishing) posing as 'tech support' to panic users into handing over Signal and WhatsApp recovery keys.
The tradecraft here is psychological rather than purely vulnerability-based, but the implications are severe. By gaining access to the recovery key or Signal PIN, attackers can bypass device registration locks and silently add secondary devices to monitor encrypted traffic.
Since these attacks rely on social engineering, technical defenses need to focus on the 'installation' phase or the command-and-control (C2) domains. If you are managing mobile fleets, you might want to scrutinize MDM logs for profiles installed outside of corporate policy windows.
I threw together a quick Python script to audit Signal's config.yml on Linux/macOS endpoints for 'linked_devices' anomalies. This won't stop the smish, but it helps detect if a user fell for it and linked a rogue device.
import yaml
import os
from datetime import datetime, timedelta
signal_config_path = os.path.expanduser("~/.config/Signal/config.yml")
threshold_days = 1
if os.path.exists(signal_config_path):
with open(signal_config_path, 'r') as f:
config = yaml.safe_load(f)
# Check last linked device timestamp (hypothetical field)
last_linked = config.get('linkedDevices', {}).get('lastLinkedTimestamp')
if last_linked:
link_time = datetime.fromtimestamp(last_linked)
if datetime.now() - link_time < timedelta(days=threshold_days):
print(f"[ALERT] New device linked recently: {link_time}")
Given that SMS is inherently insecure, are any of you forcing users to use VoIP numbers or separate authentication apps for these specific messaging platforms? Or is this just a training nightmare?
Nice script. From a SOC perspective, we are struggling to get visibility into Signal/WhatsApp logs since they are client-side encrypted. We've shifted focus to the DNS layer. The phishing kits used in these campaigns often resolve to specific TLDs recently registered. We have a Sigma rule kicking on any internal DNS request to domains registered < 30 days ago, preceded by an SMS link click (if we have mobile telemetry).
detection:
selection:
query|contains:
- '.top'
- '.xyz'
condition: selection | length(template_new_domain) < 30
It's noisy, but it catches the staging domains before the C2 activates.
The 'Tech Support' angle is the killer here. Users are conditioned to trust 'Security Alerts.' We've started rolling out FIDO2 hardware keys strictly for corporate email, hoping that by compartmentalizing auth methods, users won't confuse their Google login recovery with their Signal PIN.
However, for personal devices of execs, it's tough. We recommend enabling 'Registration Lock' with a PIN inside Signal, but if the user hands that PIN over to the 'support agent' on the phone, the lock is useless. It's a people problem, not a tech one.
I've seen similar tactics used by Scattered Spider, but this Russian op is much more persistent regarding the 'Recovery Key.' They know that if they get the key, they own the account history forever.
For detection on Windows, you can check the SQLite databases used by the desktop clients. If the last_seen timestamp in the database updates when the user is allegedly 'offline' (according to VPN logs), you have a compromise.
Get-ChildItem -Path "$env:APPDATA\Signal" -Filter 'db.sqlite' -Recurse | ForEach-Object {
Write-Host "Checking DB: $($_.FullName)"
}
Just remember, forensic acquisition of these live databases can corrupt the keyfiles if the client is running.
The panic angle makes this effective. Defensively, we need to detect if a new device was registered post-incident. Since the Safety Number changes, we can automate the comparison against a trusted baseline to catch the takeover before lateral movement. For those handling IR, a quick check helps:
# Compare against stored Safety Number
if safety_number != trusted_baseline:
raise alert("Potential APT29 pivot - Device mismatch")
Educating users to verify Safety Numbers during 'tech support' calls is a solid defensive layer.
The policy angle is crucial here. We updated our Incident Response Plan to treat the disclosure of a recovery key as a "Confirmed Breach" to trigger immediate resets.
We also added a specific verification workflow to our Help Desk documentation. Users must verify their identity via a pre-established channel, distinct from the one under attack.
markdown
Help Desk Identity Verification
- Do not accept PINs/Keys over chat/phone.
- Verify via internal employee ID or video call.
- Log request in ticketing system first.
Solid point on the IR updates. From an OSINT angle, tracking the domains hosting these fake support forms is vital. APT29 often reuses infrastructure or naming conventions. You can proactively hunt for staging sites by monitoring Certificate Transparency logs for certificates issued to domains with 'support' or 'verify' in the CN that match their known IP ranges.
# Monitor CT logs for suspicious recovery domains
curl -s "https://crt.sh/?q=%.support&output=" | jq -r '.[].name_value' | sort -u
Building on the detection angle, from a CloudOps perspective we’ve started hunting for the specific WebSocket handshake at the proxy layer. If an authenticated user triggers the 'Link New Device' API call without a corresponding helpdesk ticket, we trigger an auto-isolation rule.
Here is the KQL query we run in Sentinel to flag these linkage events:
DeviceNetworkEvents
| where RemoteUrl has "signal.org" and RequestUri contains "/v1/devices"
| where ActionType == "ConnectionSuccess"
| project Timestamp, DeviceName, SourceIP
On the endpoint side, we’ve had success querying the local Signal database directly to spot unauthorized device links before cloud logs update. Since Signal Desktop stores linked device info locally, you can extract the 'lastActive' timestamps. If you have the SQLite binary handy, this query helps verify if a new device was added during the incident window:
$dbPath = "$env:APPDATA\Signal\sql\db.sqlite"
.\sqlite3.exe $dbPath "SELECT name, lastActiveTimestamp FROM devices ORDER BY lastActiveTimestamp DESC;"
It’s a decent forensic bridge until we get better API support for enterprise monitoring.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access