The attack described is website defacement, which occurs when an attacker gains the ability to modify the content of a website—often the homepage—to display unauthorized messages, propaganda, or vandalism. The scenario explicitly says Mia “alter[s] visible content on the homepage, replacing it with unauthorized messages,” and emphasizes the reputational harm even without data theft. That reputational impact is a hallmark of defacement: it undermines customer trust, signals weak security, and can create regulatory/brand consequences even if no confidential information is exfiltrated.
The stated entry point—“exploiting an unpatched vulnerability in the web server”—is also consistent with defacement. Attackers frequently leverage web server or web application weaknesses (misconfigurations, known CVEs, weak credentials, vulnerable plugins, or insecure file permissions) to gain write access to web content or templates. Once write access is achieved, the attacker can replace HTML pages, alter templates, inject malicious scripts, or modify assets so that visitors see the attacker’s message.
Why the other options are less appropriate:
DNS hijacking (A) redirects users by changing DNS resolution so that the domain points to an attacker-controlled server. That can lead to a fake site, but it’s not the same as modifying the real server’s homepage content.
Frontjacking (B) typically involves UI deception—overlaying or framing content to trick users—rather than server-side modification of the homepage.
File upload exploits (C) are a method that can be used to gain code execution or place malicious files on a server, but the question asks for the type of web server attack being demonstrated. The visible outcome described—unauthorized homepage changes—is best categorized as defacement.
Therefore, Mia is most likely demonstrating D. Website Defacement.
