KC7 VirusTotal Fundamentals Walkthrough

Summary

The video is a guided walkthrough of KC7’s VirusTotal Fundamentals game. The presenter works through its three sections—VirusTotal 101, 102, and 103—using the questions to demonstrate how to investigate files and related indicators.

The central lesson is to interpret VirusTotal reports carefully and combine multiple sources of evidence rather than treating any single detection or field as conclusive.

Getting help and using the game

The presenter shows how to find the game through KC7’s “Search all games” page and how to report a broken feature or other problem. Reports should describe the issue and must not include passwords or confidential information.

Players who need help can use the KC7 Discord community. Before asking, they should:

1. Read the question carefully and make a genuine attempt.
2. Check available clues and analyst notes.
3. Use the channel for the correct game.
4. Search for unfamiliar concepts.
5. Explain what they have tried and what they are unsure about.
6. Be patient, and ask for guidance rather than direct answers.

VirusTotal basics and safe use

VirusTotal analyzes files, URLs, domains, and IP addresses using results from many security providers. A free account is recommended for accessing more features and community information, although some VirusTotal functions require paid access.

Uploaded files should be treated as public. Organizations with appropriate access may be able to download them, so confidential files and employer-owned files should not be uploaded.

VirusTotal is useful not only for recognizing malware, but also for identifying legitimate files that could be mistakenly flagged or blocked.

Interpreting a file report

The walkthrough demonstrates how to assess fields in a file report:

• Detection rate: The number of security engines flagging a file compared with the total number of engines. A low score—or even zero detections—does not by itself prove that a file is safe.
• Header and file name: The header includes a hash, a meaningful name, file type, size, and report information. The displayed name may come from embedded metadata or previous uploads and may not match the name of the current upload.
• Known distributor label: This can indicate that a file came from a trusted source, but investigators should still verify the hash and context. A legitimate file might be involved in loading malicious code, be renamed to look like something else, or come from a supplier that has itself been compromised.
• File metadata and dates: The report distinguishes items such as first submission, last analysis, and file creation time. Creation dates can be unusual or misleading because developers and compilers can set or reuse timestamps. Check what each date represents rather than assuming it reliably indicates when a file was created or first appeared.
• Reanalysis: Rechecking a file can be useful when an old report may not reflect newer detections or when a newly emerging file has not yet been widely detected.

Names, masquerading, signatures, and certificates

Changing a file’s name does not change its hash. A familiar-looking name therefore does not establish that a file is legitimate.

The presenter discusses masquerading—altering a file’s name, location, or other characteristics to make it appear benign—and connects it to MITRE ATT&CK. DLL search order hijacking is presented as a sub-technique of execution-flow hijacking: an application may load a malicious DLL if it searches for a library by name and finds an attacker-controlled copy in an earlier location.

Digital signatures can help establish who signed a file and whether it has been altered since signing, but a signature is not absolute proof of trust. The signer should make sense for the file, and certificates can be abused or revoked.

Version information such as copyright, product description, and original file name is supplied by the file’s creator, so it should be trusted only when the file itself is trustworthy. The walkthrough also discusses checking compiler details and recognizing that some apparently odd timestamps can be normal for files built with particular tools.

Using detections and community information

VirusTotal aggregates results from many security providers. The presenter cautions against deciding that a file is malicious merely because it has some detections; analysts should examine which providers flagged it and what labels or context they provide.

Logged-in users may see community contributions such as comments, collections, graphs, YARA rules, and Sigma rules. These can provide useful context about a file, its possible malware family, or related campaigns. However, community content also needs evaluation: comments may be inaccurate or deliberately misleading, so the author’s history and other evidence matter.

The walkthrough demonstrates using community comments to investigate a reported malware family and distribution method, and using a YARA rule match as a clue about encrypted or obfuscated content. It also connects malicious advertising to a MITRE ATT&CK sub-technique and discusses the 2023 compromise of 3CX as an example of a supplier-related incident.

Pivoting from files to infrastructure

Pivoting means using an indicator found during an investigation—such as a hash, domain, or IP address—to explore related reports and discover additional evidence.

The presenter uses the Relationships tab to examine domains and IP addresses associated with files, including passive DNS information and files that communicate with an address. When comparing infrastructure dates, the walkthrough uses a file’s first-submission date as a reference point for evaluating nearby DNS resolution dates.

Related files, suspicious domains, and IP addresses can help analysts build a broader picture, but relationships should be checked rather than assumed to prove malicious activity. The Relationships tab can also show execution parents. A parent archive may contain a file that VirusTotal analyzes separately, and the archive’s contents and hashes can be inspected.

Examining behavior and sandbox results

The final section focuses on behavior reports and how a file acts in an isolated analysis environment. Sandbox results can show file-system activity, registry changes, network connections, and process creation.

• File size and sandbox limits: Large files may exceed the limits of some sandboxes. The walkthrough describes file inflation as a way attackers may hinder analysis and mentions deflating a file to make it easier for more sandboxes to inspect.
• File-system activity: This can reveal persistence mechanisms, such as files placed in a Windows Startup folder.
• Registry activity: This can identify modified hives and values. The presenter demonstrates locating the full name of the HKCU hive and inspecting a registry value associated with a program-launch command.
• Process trees: These show parent–child relationships. In the example, the analyst follows the tree to identify a child process.
• Other behavior: The behavior report may also reveal cryptographic references and other actions, but those details should be interpreted in the context of the complete report.

Overall lessons

• Treat VirusTotal as an investigative resource, not an automatic verdict.
• Verify file identity with hashes and compare indicators across report sections.
• Distinguish file metadata from independently verified facts; fields supplied by a file or user can be misleading.
• Evaluate signatures and detections in context, and consider both benign and malicious explanations.
• Use community content and relationships as leads to investigate, not as proof on their own.
• Record and pivot on useful indicators to expand an investigation from a file to related infrastructure and behavior.

Speakers and sources featured

• Speaker: One presenter, who introduces himself in the subtitles as “Dart Pshock.” The subtitle rendering of the name may be inaccurate.
• KC7: The game platform, VirusTotal Fundamentals game, analyst notes, reporting feature, and Discord learning community.
• VirusTotal: The main investigation platform, including file, domain, and IP reports; community comments; collections and graphs; relationships; and sandbox behavior.
• MITRE ATT&CK: Referenced for technique definitions and technique IDs, including masquerading, DLL search order hijacking, and malicious advertising.
• VirusTotal community contributors: User comments and contributed YARA and Sigma rules are discussed; the game’s contributors are acknowledged but not named in the subtitles.
• Other tools and references mentioned: Dr.Web VX Cube sandbox results, the DeepBloat tool, Google searches, and external blog material about file timestamps.
• Examples and entities discussed: Microsoft, Intel, Borland Delphi, and the 3CX compromise.