On February 18, 2025, Margaret was browsing the web looking for Thanksgiving recipes when her browser suddenly displayed a full-screen warning. The page claimed her computer was infected with viruses and locked her browser.
Frightened, Margaret called the phone number displayed on the screen. A man answered and claimed to be from Microsoft Support. He convinced her that hackers were actively stealing her information and she needed to act immediately.
The man instructed her to download a program that would let him “fix” the problem remotely. Once connected, he spent over an hour “cleaning” her computer while showing her scary-looking windows and error messages.
At the end, he demanded $500 for a “protection plan” and insisted payment be made with gift cards for “security reasons.” Margaret drove to Target, purchased the cards, and read the numbers over the phone.
As a DFIR analyst your job is to analyze Chrome browser data and AnyDesk application data.
A recipe search led the victim through a chain of pages to a malicious redirect domain and finally a full-screen scareware page that displayed a fake Microsoft support phone number. Calling it put her in touch with a scammer posing as Microsoft Support, who talked her into installing AnyDesk and connecting to his own machine. The AnyDesk trace records the connection under a support-themed alias, a session of a little over an hour, and file transfers that began with a sensitive document from her Desktop. Chrome’s History database and cache preserve the whole browsing side of the story, and the AnyDesk files carry the remote side. The incident ended with a gift-card payment demand, which no artifact here can show.
intelvol.raw → a single FAT volume. Extract it with 7z and work on the extracted treeHistory → SQLite database (urls, visits). Query with sqlite3Cache_Data/ → cached page bodies. Read with stringssystem.conf, ad.trace, connection_trace.txt → plain text, read with cat and grepTimestamp note: The
Historydates fall on 2025-01-30, not the February 18 date in the scenario. Nothing in the questions depends on the date, so don’t let the mismatch send you hunting for a second profile.
Extract the image and open History. The urls table in id order starts with a Google search for Thanksgiving recipes, followed by a recipe site, and only then the scam pages. The first site visited is Google itself, so the answer is its hostname rather than the recipe site.
7z x -owork/fs evidence/intelvol.rawsqlite3 History "select id, url, title from urls order by id"Gotcha: The format mask is three-part and dotted. The recipe site that sits between the search and the scam is a tempting answer, but the question asks for the first site.
From Q2 we have the start of the chain: search, then recipe site. Follow the from_visit links in visits forward from the recipe site. The first hop that leaves the recipe site lands on a lookalike security-alert domain (urls id 4), which then leads to the scam page.
sqlite3 History "select v.id, v.from_visit, u.url from visits v join urls u on u.id=v.url order by v.id"The scam page body sits in the Chrome cache as Cache_Data/f_000a1b. It is mostly HTML, so strings plus a grep for the phone element is enough. The number sits in a .phone div.
strings Cache_Data/f_000a1b | grep -i phoneCount the rows in urls. The whole history is a single browsing session, so the full row count is the answer.
sqlite3 History "select count(*) from urls"Gotcha: The History timestamps are on a different day from the scenario date (see the timestamp note). Don’t filter by the scenario date, or you will count nothing.
AnyDesk stores the local ID in system.conf as the id= line, and ad.trace logs the same value as the assigned ID at startup. Both agree.
cat AnyDesk/system.confThe remote peer is in connection_trace.txt, and ad.trace shows the same ID on the incoming connection. Don’t confuse it with the victim’s own ID from Q1.
cat AnyDesk/connection_trace.txtFrom Q5 we know the remote ID. Search ad.trace for the Alias field attached to that connection.
grep -i alias AnyDesk/ad.tracead.trace writes a Session duration line when the connection closes, already in seconds, so no timestamp arithmetic is needed.
grep -i 'session duration' AnyDesk/ad.tracead.trace logs each file transfer with its path. Read the transfers in log order and take the first one from the Desktop. Report only the filename, not the path.
grep -i desktop AnyDesk/ad.traceThe transfer summary at the end of ad.trace gives the session total in bytes. It covers the Desktop files from Q8 and any others taken in the same session.
grep -i 'total transferred' AnyDesk/ad.trace| Phase | Action |
|---|---|
| Initial Access | Victim searches for recipes on Google and follows a recipe site |
| Initial Access | A redirect through a lookalike security-alert domain lands on a full-screen scareware page |
| Initial Access | Victim calls the fake Microsoft support number shown on the page |
| Command and Control | Victim installs AnyDesk and the scammer connects under a support-themed alias |
| Exfiltration | During a session of just over an hour, the scammer copies files off the Desktop, starting with a bank statement |
| Impact | Scammer demands a $500 gift-card payment (from the scenario, not an artifact) |
| Type | Value |
|---|---|
| Domain (redirect) | ww1[.]windows-security-alert[.]com |
| Phone number | +1 (888) 351-4019 |
| AnyDesk ID (attacker) | 529481627 |
| AnyDesk alias | MicrosoftSupport |
| AnyDesk ID (victim) | 847291503 |
| File (stolen) | Bank Statements 2024.pdf |
| Cache file | Cache_Data/f_000a1b |
| Technique | ID | Description |
|---|---|---|
| Phishing: Spearphishing Voice | T1566.004 | Scareware page pushed the victim to call a fake support line |
| Remote Access Software | T1219 | Victim-installed AnyDesk gave the scammer an interactive session |
| Exfiltration Over C2 Channel | T1041 | Desktop files copied out through the AnyDesk session |
| Financial Theft | T1657 | Gift-card payment demand for a fake protection plan |
Unapproved remote access tools need a block or an alert. AnyDesk was installed and used by a home user within one phone call. Application allow-listing, or an alert on first execution of remote-access software, closes the window that the scammer relied on.
Chrome’s History and cache keep the whole lure. The redirect chain in visits and the cached scam page expose the redirect domain and the phone number even after the tab was closed. Both are worth collecting early, since the phone number is a ready-made indicator for takedown requests.
AnyDesk’s own logs answer the scoping questions. ad.trace holds the remote ID, alias, duration, transferred files and total bytes. Collect %AppData%\AnyDesk and ProgramData\AnyDesk on any remote-support-scam report, because they say exactly what left the machine.
Sensitive documents on the Desktop are the first thing taken. The first transfer was a bank statement, so anything the scammer saw on screen counts as exposed. Moving financial documents out of obvious locations limits what a short session can grab.
A recipe search turned into a remote session with a scammer, who took a bank statement and other files before asking for gift cards. Everything needed to scope it sits in two places, Chrome’s History and cache and AnyDesk’s logs, and both survive long after the call ends.