Written by: Joseph Salazar, Technical Marketing Engineer – *Best read in the style of Rod Serling* Picture if you will, an attacker breaking into a computer system for a retail organization he’s been targeting for a few months. He’s managed to trick a user into clicking on a malicious email with custom malware that evaded detection and now has remote access to the network. He installs some back doors to make sure he can get back in, and then decides to steal some credentials. He finds one that looks promising called “sqladmin” in the credential manager. To make sure it is legitimate, he spins up a command prompt, queries Active Directory for the “sqladmin” login, and confirms that it is authentic. He then looks up the IP address of his beachhead system and pings the next system up from it (because only script kiddies scan the entire network). Just his luck, the IP address responds. Little does he know that he’s about to enter into the Twilight Zone.
The attacker runs a quick port scan for the 100 most common ports on the target IP address with nmap -F and gets excited when he sees several ports open, including ports 80, 443, 22, and 1433. He quickly recognizes services ports for web, secure shell, and SQL server services and thinks he’s found a web server with a SQL database attached to it. Using the “sqladmin” account he stole, he attempts to authenticate and… SUCCESS! As he’s rooting around, he finds a database with what looks like gift card information with various amounts of money associated with each card entry. Maybe this is a company gift card repository with a web page for customer access. Time to do some shopping!
Right before he begins packaging the data for exfiltration, he suddenly loses connection to the beachhead system. No worries, he installed some back doors… but none of them are working. He tries to connect from his C2 server and nothing. He uses a VPN connection to a proxy server in the cloud to try again, but nothing he does gets him access. Did the system reboot? Did it crash? Over the next few days, he keeps trying to regain access, but to no avail. Somehow, the company detected him and kicked him out. He was SO CLOSE! All those gift cards for the taking! What went wrong?
What went wrong in this scenario was the Endpoint Detection Net (EDN) Deflect function doing its job. What the attacker didn’t know was that the company he targeted was using the Attivo ThreatDefend platform and had deployed the EDN suite to all of its endpoints. All the information he stole or accessed on the beachhead system was, in fact, deception (fake!), from the “sqladmin” credential to the AD information to validate it. The EDN Deflect function was responsible for the decoy port scan responses from the IP address he had pinged as his next target.
The EDN Deflect function looks for unauthorized port and service scans and forwards both inbound and outbound connections to a decoy with a corresponding open port and service attached to it. Because it only responds to closed ports, it will not impact production ports and services that are open for operations. In practical terms, the EDN Deflect function makes every protected system part of the decoy environment. Any attempt to connect to any closed port results in a response from a decoy, making individual host fingerprinting difficult. Connection attempts forward to virtual decoy systems, which respond to the attack while generating alerts and denying the attacker the ability to discover other targets or move around laterally while staying undetected.
In the above example, the IP address the attacker pinged was, in fact, just another endpoint. The EDN Deflect function forwarded the port scans and connections to the decoy card registry while notifying the security team. The EDN Deflect function detected and alerted on the outbound port scan to the target IP, and the target IP sent a similar alert when the attacker’s scans attempted to connect to the closed ports on port 22, 80, 443, and 1433. The beachhead system’s EDN Deflect module then forwarded the outbound traffic to a decoy web server that the company had configured to look just like a web server for their gift card registry. Thanks to the BOTsink deception server’s stable of full OS virtual machine decoys, the company even configured the fake server with a corresponding decoy SQL database complete with decoy card data.
The security team quickly realized that the decoy registry server was under attack and promptly isolated the attacking system’s IP address with the EDN Deflect quarantine function, limiting the attacker’s inbound and outbound traffic to communicate only with the decoy environment. This move cut the attacker off before he could exfiltrate the valuable gift card data and prevented any further damage. Ultimately, the attack was stopped early in the attack cycle during the initial reconnaissance and lateral movement phases, limiting the effects of the compromise.
By providing a unique line of defense, the EDN Deflect function sent the attacker to the decoy environment but let him think he was interacting with a production system. It also made a standard endpoint look like a web server with an SQL database attached. The ability to make every production endpoint part of the decoy environment is a significant advantage for any security team. With the EDN Deflect function, the next time an attacker attempts to infiltrate the network, they may just find themselves on their way into the Twilight Zone.