How a Designer’s Stolen Passwords Nearly Tanked a Startup [MITRE: T1078 — Valid Accounts]

​Incident Description: The attacker uses stolen credentials to access the company’s server, website, or cloud.

Incident Description: The attacker uses stolen credentials (for example, from an employee or contractor) to log into the company's server, website, or cloud.

Response Plan:

  1. Detection: Notice suspicious activity in logs (for example, login at night).

  2. Blocking: Disable the account and change all passwords.

  3. Notification: Inform management and check what data might have been stolen.

  4. Verification: Review the attacker's actions in the system.

  5. Hardening: Restrict access by IP and update password policies.

  6. Investigation: Determine how the data was stolen (phishing, leak).

Cybersecurity: hacking stories and protection! Join: https://t.me/scontrols

What can go wrong:

  • Logs are not kept, and activity cannot be traced.

  • The administrator doesn't know how to block the account.

  • Passwords are the same for all systems, and the breach spreads.

  • There is no list of who has access to the servers.

  • The dismissed employee was not removed from the system.

  • There are no tools for analyzing suspicious activity.

At the office of the startup "FutureFlow," which is developing an application for small business financial management, life was buzzing. Developers argued about new features, marketers were designing banners, and CEO Lera inspired everyone with speeches about the "fintech revolution." The technical infrastructure was simple: a terminal on Windows Server 2012 in a back room, with no antivirus or intrusion prevention systems, plus cloud hosting for the application. IT was managed by Dima, a system administrator with five years of experience, who preferred fixing printers to dealing with security. "Who would want to hack us? We're a startup, not a bank," he would joke, sipping energy drinks.

The key freelancer was Alexandra, an outsourced designer. She worked for three companies, including "FutureFlow," creating logos and interfaces. She was granted RDP access to the terminal server via her home computer—without checks, just port 3389 was forwarded. Alexandra was talented but had only basic knowledge of cybersecurity, at the level of "turn it off and turn it on again." The passwords for all accounts—at "FutureFlow," other companies, and her personal email—were the same: "SashaDesign123." Password manager? "Why, I remember everything," she would laugh.

The Beginning of the Trouble

The trouble started outside "FutureFlow." On Tuesday evening, Alexandra received an email from the "IT department" of another company: "Urgently update your access, your password is about to expire." The link led to a fake page mimicking the corporate portal. Tired, she entered "SashaDesign123" and didn’t notice how her data was sent to the hacker. An hour later, he was sitting on her Windows 10 laptop, which she never turned off. The attacker surveyed the situation: saved passwords in the browser, RDP shortcuts to three companies, including "FutureFlow," on the desktop. From the messenger conversations, he understood that she finishes work by midnight and doesn’t respond until the morning—she definitely wouldn’t be at the screen at 4:00 AM. Jackpot.

The Night of the Invasion

At 4:00 AM on Wednesday, a hacker connected to the “FutureFlow” terminal server via RDP from a South African IP, using “SashaDesign123”. Windows Server 2012 accepted him as a legitimate user — no antivirus, no IP filters. The logs were running, but Dima didn’t check them — “didn’t want to waste space.” The intruder acted quietly: downloaded a database with 5,000 users (names, phones, transactions) and the application source code. Then he installed a backdoor — a script disguised as svchost.exe in C:\Temp, which sent data to a remote server every 30 minutes. Through messenger, he sent a message on behalf of Alexandra: “Colleagues, check out the new layout at the link.” The link led to a phishing site, but no one had clicked yet.

The hacker leaked data in small batches, connecting from different IPs — Africa, Asia, Eastern Europe — to avoid suspicion. His goal wasn’t extortion, but unnoticed data collection for sale on the darknet.

Accidental Discovery

On Friday morning, a developer complained to Dima that the internal task tracker was lagging. “Broken code again,” Dima muttered, opening the server console. In Task Manager he noticed svchost.exe eating 20% CPU — the backdoor was actively transmitting data. Dima checked the connection logs and was stunned: logins via RDP at 4 AM on Wednesday and Thursday from a South African IP. “Alexandra? She doesn’t need the tracker, she’s a designer! And why Africa?” he murmured, dropping his energy drink.

He called Alexandra: “Sash, were you working at 4 AM from Africa?” She sleepily replied: “What? I’m in Moscow, I’m asleep at that time.” Dima turned pale: “Looks like we’ve been hacked.”

Chaos in Action

Dima rushed to block Alexandra’s account in Active Directory, but he forgot the admin password — had to search for the note under the keyboard. While he fumbled, the hacker ended the session, leaving the backdoor running. Dima disabled Alexandra’s access, but didn’t touch other accounts — “no time.” He called Lera: “Someone broke in through Sasha!” Lera burst into the back room: “Where’s my data?!” Dima showed her the suspicious process, but with no antivirus and only three days of logs, he didn’t know what was stolen. Alexandra admitted during a call: “I entered the password in an email from another company… I use the same one everywhere.” Dima cursed: “Are you serious? You’ve set us up!”

Consequences

The developer clicked the phishing link from messenger — his laptop got infected, and through it the hacker obtained even more data. The user database leak made it to the darknet — a week later, clients started complaining about spam and fraud. Backups were a month old, the latest data partially lost. Lera gathered everyone: “We’re losing trust! What do we do?” Dima closed RDP and suggested two-factor auth, but the damage was done.

A month later, “FutureFlow” lost 30% of its audience, investors reviewed their funding plans, and their reputation took a hit. Dima blamed Alexandra, she blamed him for lack of security. Lera hung up a sign: “One password — one disaster,” but the startup was recovering for a long time.

Would You Have Noticed?

One phishing, one account — and the startup is on its knees. How would you protect your network from this?

Share in the comments!

Comments