Exposed RDP and a Shared Admin Account at an Accounting Firm
A 40-person accounting firm runs a Windows file server and a remote desktop gateway on-premises. To let staff work from home, the IT consultant forwarded TCP 3389 on the firewall to the gateway and enabled a shared local administrator account. The firewall log shows about 12,000 failed login attempts per day from five countries, and one account was locked out after 300 attempts. The firm's clients require confidential tax data to stay on the firm's network. Staff use personal home routers and sometimes public Wi-Fi. The partner wants a VPN because 'that is what banks use,' but the consultant says a VPN alone will not fix the problem. The firm has 40 laptops, no MFA, and a budget for one project this quarter. The firm also runs an unpatched webmail portal on port 443 that uses the same password policy.
1. Explain why exposed RDP and a shared admin account are high risk, and why a VPN alone is not enough.
Read the worked answer
Exposed RDP is a direct login service reachable from the internet. Attackers can brute-force, password-spray, or use credentials from other breaches against it. A shared local administrator account removes individual accountability: logs cannot show who did what, one leaked password gives many people admin access, and the account cannot be disabled cleanly when one person leaves. The failed-login volume shows active targeting, not a theoretical risk. A VPN encrypts the tunnel and hides RDP from direct scanning, but it does not fix weak or shared credentials. If an attacker phishes a VPN password, the attacker is inside the trusted network. The VPN also does not patch the webmail portal or enforce least privilege. A safer design removes the RDP port forward, requires MFA on VPN, uses named accounts, restricts RDP to the gateway after VPN, and patches internet-facing services. The VPN is a transport control, not an authentication or authorization strategy.
2. Propose a remote-access architecture for the 40 laptops within one project budget.
Read the worked answer
Remove the TCP 3389 firewall forward first. Deploy a VPN concentrator or the firewall's VPN with MFA, and allow RDP only to the remote desktop gateway after VPN authentication. Give every user a named account; disable the shared local administrator account and use a separate, audited emergency admin process. Enforce least privilege so staff reach only the file share and applications they need. Patch the webmail portal and put it behind MFA or a reverse proxy with rate limiting. For personal home routers and public Wi-Fi, require the VPN for all work access and use endpoint protection on the 40 laptops. If budget forces a choice, prioritize MFA plus removal of exposed RDP over a fancy VPN brand. A reasonable sequence is: close the port, enable MFA, fix accounts, patch webmail, then tune logging. Do not promise that VPN alone solves the problem; the project must include identity and patching.
3. What logs and alerts would you require, and what is the first incident-response step if a login succeeds from a foreign IP?
Read the worked answer
Collect VPN authentication logs, RDP/gateway logs, firewall denies, webmail authentication logs, and MFA logs. Alert on many failures followed by a success, logins from new countries, impossible travel, logins outside business hours, and use of the shared admin account. Retain logs long enough to investigate, at least 90 days if feasible. If a successful login appears from a foreign IP, do not start by rebooting the server. First revoke the user's sessions and VPN tokens, disable the account if compromise is suspected, and preserve logs. Check what the session accessed and whether files were copied. Isolate the endpoint if malware is suspected. Then reset credentials, enforce MFA re-enrollment, and review firewall rules. Notify the partner and client-facing owners if confidential tax data may have been accessed, following legal advice. The first step is containment with evidence preservation, not immediate reimaging.