Introduction
This is the twenty-second in my Security Series of Connect articles. For more information on how to keep your enterprise environment secure using often-overlooked capabilities of Symantec Endpoint Protection (and the OS upon which it functions), see Mick's Greatest Hits: Index of Helpful Connect Security Articles. This article was last updated in June 2018.
We now continue a mini-series illustrating how an admin can use Symantec Endpoint Protection (SEP) to overcome security challenges in an organization. IT admin Johnny has successfully eradicated all trace of unwanted Miners in the remote O. P.'s Foodmart network, a poorly-organized organization with whom his company has recently merged. But it appears that someone or something in that environment has set its sights on removing SEP.
One Tiny Spark Becomes A Night Of Blazing Suspense
The initial weeks after the merger were malware madness. Johnny had come into the office every morning, checked the Risk report and Network Threat Protection-Attacks report from his Symantec Endpoint Protection Manager (SEPM), then spent the whole day firefighting. The newly-joined network had no shortage of infected computers to identify, isolate, clean, harden and re-join. At last, though, the crisis was over. The morning reports showed up clean. Time to heat up the coffeepot on the front burner and tackle the to-do tasks that had been pushing to the back burner! Finally, the chance to migrate every workstation from old ad-hoc WORKGROUPS to a modern Active Directory Domain infrastructure....
An emergency IT ticket from O. P.'s Foodmart dashes those hopes. A critical Windows 7 computer, running slow, with unexpected processes consuming power and bandwidth? Oh no. Johnny connects in via RDP and opens Windows Task Manager:
Xmrig.exe! A coinminer, running again-? How? And how come this is not stopped by SEP? Or showing up in his SEPM alerts and reports?
Johnny opens the mysterious process's location and checks its Properties...
Who is this unexpected "notadmin" user-? He asks the end user who raised the IT ticket, but there are no answers there. "I just log into everything as Administrator / Password123, the same as I've always done."
Then he asks Johnny if the computer is fixed yet and what's the holdup?
Johnny smashes a stressball into pulp to check the Local Users for this Windows 7 machine... "notadmin" is not alone.
Caught in a game of power. Playing time: 24 hours. Prizes: Untold wealth. Rules: None.
Time for immediate action: Johnny disables the unauthorized account "notadmin" and another that had admin permissions- "freemoneyhahaha."
Where did these come from-? Incident Response and Digital Forensics are the advanced IT disciplines capable of answering those questions. Johnny has never received that specialized training and does not know how to use those tools. SEP is certainly not a DF/IR tool- it's for fighting malware. Without calling in DF/IR gurus there's no way to be 100% sure how those accounts came to be on the machine and what actions they have done. However, Johnny does know a quick trick or two with the built-in Windows Event Logs. There should be a Event ID 4720 recorded when a new user is created... sure enough:
Ok! Just created a day ago. This computer- and whatever access it has on the wider network- has not been pwned for long.
Now! What has "freemoneyhahaha" been up to-?
No wonder SEP did not stop the miner or report any blocked detections to its management component. EventID 11724 indicates that Windows' built-in, legitimate MsiInstaller removed SEP entirely. Once a user with valid administrator credentials has access to a computer- either sitting locally at the keyboard, or connecting in from a remote location- they can do whatever they want. It's game over.
What Happened to Them Could Happen to You ... In Any City Anywhere!
A little more amateur detective work: expanding the logs to display the TerminalServices-RemoteConnectionManager entries, sure enough there is evidence that shortly before that new "freemoneyhahaha" account was created, an outside visitor connected to the computer using RDP: Windows' built-in, legitimate Remote Desktop Protocol. The same tool that Johnny himself was using.
Apparently someone from whatever corner of the world found this computer's RDP port open twenty-four hours a day, tried the valid Administrator/Password123 combination, and laughed out loud. Then they created their own Admin account in case someone at O.P.'s Foodmart woke up and changed the built-in Administrator account's password to something slightly secure.
EventID 4648 showed a later "freemoneyhahaha" connection, including the remote Network Address:
Johnny quickly crafted a rule at the corporate firewall to block any future connection attempts from that IP Address. It was unlikely to slow an intruder down, but Open Source Intelligence confirmed that this was one IP with a bad reputation.
The intruder also created the "notadmin" account and sold that to a coinmining friend, apparently. EventID 21 showed logins for that account, too:
What else were they doing when logged in with Administrator rights? What other backdoors had they planted or user accounts created throughout the network? Why was this end user on the phone still asking if he could have his computer back now to continue working on important top-secret company strategies?
"Not a chance. Picture everything you can access. For the past twenty-four hours our intruders could access it, too. No matter what the cost, we've got to isolate this machine and call in Incident Response. I hoped to go home and have a 70sdisastermovie marathon! Now I'm in a modern-day one."
It will be a long night, but there are certain things that must be done when a breach is discovered.
Conclusion and Resources
Thanks for reading this illustration! Infections like the one above happen every day. The malware planted- and often planted widely- by the intruder is typically not a miner. It's Ransomware. If an attacker can access the network with valid credentials guessed, brute-forced, or purchased from dark markets, there's no need for super-advanced malware. Intruders can lower the defenses and use any old form of destruction they like. Prevention is far better than cleaning up, after.
To prevent a situation like this:
- Add all computers to the centrally-managed Active Directory Domain rather than the old-fashioned Workgroup
- Harden the Domain’s security. Be sure to enforce a strong password policy, control who can create new accounts, and what accounts can use RDP and during what hours.
Best Practices for Securing Active Directory
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory
- Ensure that SEP has an uninstall password and cannot be disabled easily.
Password-protecting the Symantec Endpoint Protection client
http://www.symantec.com/docs/HOWTO81235Preventing users from disabling protection on client computers
http://www.symantec.com/docs/HOWTO81223
- Continuously check the network for undefended endpoints! Every computer must have security software installed.
Configuring a client to detect unmanaged devices
http://www.symantec.com/docs/HOWTO80763
- Configure Windows Audit Policy for security- and monitor the logs!
Audit Policy Recommendations
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations
- Plan for what to do in case of a breach or other disaster.
If the worst has already happened and a critical system was found to have been compromised, you may need to contact Incident Response professionals. This article illustrates a few easy tips. IR pros have the toos and expertise to determine what happened even when intruders have covered their tracks.
Symantec has a dedicated IR team: to find out more, please visit:
Incident Response Services
https://www.symantec.com/services/cyber-security-services/incident-response