How a Former Employee Transferred Data to Competitors

Incident Description: A dismissed employee retained access to the system and stole data using old accounts.

Response Plan:

1. Detection: Notice suspicious activity in the logs after dismissal.

2. Isolation: Disable the employee's account.

3. Notification: Inform management.

4. Verification: Check logs for stolen data.

5. Recovery: Change the passwords known to the employee, including third-party services [especially if an administrator was dismissed].

6. Prevention: Set up a process to deactivate all credentials upon dismissal and maintain a registry of removed accesses.

What might go wrong:

— Logs are not kept or have been deleted.
— The account wasn't disabled in time.
— Passwords weren't changed after the dismissal.
— No list of the employee's accesses.
— Data have already been sold to third parties.
— No data leakage prevention system.

▰▰▰▰▰▰▰▰▰▰▰▰▰▰▰ 99%

In the small company "TechnoSoft", specializing in business automation software, Friday night seemed ordinary. The sales manager—a young, attractive woman with bright red hair and stylish glasses—announced her departure.

She was the star of the department: her charming smile and ability to close deals made her indispensable. Competitors lured her away with better terms. That evening she bought pizza for her colleagues, said her goodbyes, and left, carrying a laptop and a stack of business cards in her backpack. The team wished her luck, and the next morning her account in Active Directory (AD) was blocked. But nobody checked access to the server via Remote Desktop Protocol (RDP)—a mistake "TechnoSoft" would soon pay for.

Employees of "TechnoSoft" connected to work machines via RDP on a server running Windows Server 2019. Connection logs were recorded in Event Viewer, but sysadmins didn't monitor them—there were neither notification systems nor resources for analysis. Newcomers were given access, old sessions were not checked, and due to dynamic IPs the subnets remained open.

Sysadmins enabled local disk redirection in the RDP settings for convenient remote work, but forgot to restrict permissions, leaving the feature available to all users. The sales manager knew the sales department employee’s credentials — the login and password "Password123", which he had shared in the chat for working from home.

The sales department employee didn’t change the password out of laziness, thinking "everything works anyway," and the GPO policy required a change every 180 days. After leaving, the sales manager would connect from her home laptop via RDP using that account and copy client databases and price lists directly to her computer through local disk redirection — there were no time restrictions on access, and nobody noticed any suspicious activity.

The leak cost the company its clients

Two months later, competitors started winning tenders, offering terms almost identical to "TechnoSoft". Discounts and deadlines matched with frightening accuracy, but with a slight advantage for the client. Analysts sounded the alarm: "They know our moves!" At first, it was written off as coincidence, but after losing a major client who chose a competitor with a slightly lower price, people at the office started talking about a problem. The director brushed it off: "Coincidence." But doubts kept growing.

Competitors got the price lists

A week later, a partner — a server supplier — called: "Your former sales manager now works for the competitors and offered me discounts just a bit better than yours." Another client confirmed: "She knows our current terms and undercut them." The head of analytics called a meeting: "How is she doing this? She was removed from AD!" The sysadmins exchanged glances but said nothing — they could have checked active sessions in Remote Desktop Services, but didn’t bother.

Data leak investigation

The check showed: the sales manager’s account in Active Directory was locked. "She couldn’t log in," the admins said, not mentioning that other accounts remained active, and the connection logs gathered dust. After losing yet another client, the director barked: "Check the server!" The sysadmins changed passwords but didn’t bother digging in Event Viewer or closing old sessions — that was "too difficult."

RDP caused the leak

Another partner remarked: “Competitors, where your former employee now works, offered me better terms than you.” It became clear: the sales manager kept leaking up-to-date price lists after leaving, boosting her position at the new company. But how? The sysadmins didn’t know what to say: “RDP is open to subnets, we didn’t monitor connections.”

The audit revealed information security risks

The director gave up: “We need experts.” “TechnoSoft” hired an outsourcing company to investigate. The auditors started with port scanning using Nmap and found that port 3389 (RDP) was open on the company server. Then they checked firewall rules via Windows Defender Firewall and the router’s settings, revealing that connections to 3389 were allowed for a wide range of IPs—a whole subnet, not specific addresses. In the Remote Desktop Services Manager they found sessions left open, and multi-factor authentication (MFA) wasn’t used.

Through Group Policy Editor they uncovered a weak password policy: “Password123” met the GPO requirements, needing three out of four criteria (capital letter “P,” lowercase “assword,” numbers “123,” no special characters), but the GPO didn’t include a forbidden password check, which allowed using vulnerable combinations.

The auditors pressed Win+R, typed “PowerShell” and ran a script to output a list of domain users who hadn’t changed passwords in the last 180 days—among them was a sales department employee.

# Find AD users with outdated passwords
$maxAgeDays = [math]::Abs(
    (Get-ADDefaultDomainPasswordPolicy -EA 0).MaxPasswordAge.Days ?? 180
)
$date = (Get-Date).AddDays(-$maxAgeDays)

Get-ADUser -Filter {
    Enabled -eq $true -and 
    SamAccountName -ne 'krbtgt' -and 
    (PasswordLastSet -lt $date -or PasswordLastSet -eq $null)
} -Prop PasswordLastSet |
Select Name, SamAccountName, 
    @{N="PasswordLastSet";E={$_.PasswordLastSet ? $_ : "Never Changed"}} |
Format-Table -AutoSize

They also recommended implementing DLP-class solutions to prevent data leaks in the future.

Forensic analysis was conducted using Event Log Explorer by examining Windows system logs (Event ID 4624 for RDP logins). The logs showed connections from a sales department account outside working hours after the sales manager had left, but the exact IP couldn’t be determined due to dynamic addresses. Wireshark confirmed: data wasn’t sent over the network but was copied via RDP local disk redirection. The inquiry revealed: a sales department employee shared the password in chat, and sysadmins ignored basic practices — they didn’t monitor logs or close sessions.

Protection against data leaks

“TechnoSoft” lost three key clients, costing the company 5% of its annual revenue — direct losses from lost contracts. After that, the information security budget was doubled. RDP was replaced with VPN and MFA, access became one-time and was revoked upon dismissal. A password manager was implemented so employees would no longer store credentials in chats, along with DLP solutions to control data transfers, and logs were set up for active monitoring. The server was updated. This incident served as a lesson: neglecting security is expensive.

#Cybersecurity #DataLeak #InsiderThreat #Cyberбезопасность #ДанныхLeak #InsiderThreats