You are here

Cybercriminal intent: When good OpSec met bad OpSec

public://webform/writeforus/profile-pictures/384107-spy-and-secret-agent-and-generic.jpg
Bart Otten, Security Researcher, Hewlett Packard Enterprise

Meet Anatoly, a “legitimate” businessman from the East—better known as a cybercriminal. We know him as Anatoly, but we also know that isn’t his real name. Anatoly isn’t a typical cybercriminal; he knows how to stay safe, secure, and, most importantly, anonymous. Anatoly is a criminal with many names and very good computer and management skills, and he's a real boss.

Anatoly starts his day by booting his secure virtual machine. After connecting to his bulletproof VPN, he chooses which of his many aliases he is going to use today. He logs into his cover accounts using strong passwords generated by a password manager. Now, he is looking for freelancers to set up the new business for his customers higher up in the criminal food chain.

Once he finds freelancers to work with him, he delegates the tasks to people he knows only by their handles, same as they know him. He hires a web designer to design the websites for his fake companies, an infrastructure specialist to set up the infrastructure, and a software engineer to develop the system Anatoly will use to let people work for him.

 

Anatoly is a real people person. He sounds friendly and is always busy, just like a real businessman. He builds a good relationship with the freelancers and earns their trust. He makes a deal with them that sounds fair: “When you complete the task, you will get paid,” and halfway down the project timescale he inspects the work and lets them know they did a good job. He will pay even more than previously promised when the job is completed.

Once trust is gained, he tells the web designer how the website should look and that they will receive an email from someone (another freelancer) with the translated texts for the website. He instructs the infrastructure specialist to buy a pre-approved web-hosting service and specifies the personal details to be used to register the service. Once hosting is set up, the infrastructure specialist notifies the developer with the hosting details, giving the developer (full) access to the servers. The developer can now begin his work.

Of course, Anatoly knows that developing systems takes a lot of time, and time is money, so he’s already bought some pre-made systems from trusted sources. Anatoly instructs the developer to set up these systems first so that he can begin to realize a return on his investment much sooner. He sends the developer instructions on how to use other services, which he previously registered to save time.

After a while, Anatoly becomes a better friend with the developer and asks if he wants to earn more money by moving data from one hosting service to another. For that, he needs to become an administrator for the account, since Anatoly is too busy as a legitimate businessman.

At this point, Anatoly has his website designed, his text translated, his hosting setup, and nothing linked to his alias. He also has a developer building his new system. Anatoly has not yet paid a single dollar. The only people who know anything about him are the freelancers. Anatoly’s OpSec is bulletproof—or so he thinks.

[ Understand what's driving the next-generation SOC with TechBeacon's guide. Plus: Download ESG's report on the state of cloud-based security analytics and operations ]

Mistakes eventually happen

If Anatoly’s OpSec practices are better than the average cybercriminal's, how did we find out what he was doing? It all started with an insecure VPN server his developer used. The developer, Ivan, isn’t a good OpSec practitioner and left a trail of information behind. This time, Ivan used a cheap VPN service to work on the system he is creating for Anatoly, which is compounded by Ivan’s development skills lacking in terms of security.

After inspecting some network packets, our researchers found a website being developed by Ivan. How did we identify him? Ivan’s login process wasn’t secure. It was relatively easy to capture his login cookie, which was enough to access the private part of the website. After inspecting the website, we found vulnerabilities that could be used to upload PHP code allowing us to see how this development system works. Ivan left his personal email account details, his private Jabber account details, and additional Jabber accounts in a test file.

We examined the application database structure and checked the users table. For testing purposes, Ivan used his real name and his personal email address. Ivan also tested his PHP Jabber script with his real account—even leaving his password in the script. Worst of all, Ivan reused his password for his email account. Like many other inexperienced cybercriminals, he compromised the security of the operation.

As Ivan was developing this system, we initially believed him to be the brains behind the project. Checking the WHOIS record of the domain name used revealed that the WHOIS record contained fake information.

Wanting to know more about Ivan and where he logs into the system, our research revealed three IP addresses logging into the server. One IP address was a home connection and another belonged to a school.

Conducting a search using the email address taken from the PHP script combined with Ivan’s name and the name of the school quickly allowed us to discover a person named Ivan working at the same school. Could this be our Ivan, or does he use the university network as a proxy for his development effort?

And who is using the VPN IP address? Could this also be Ivan? In a search for this IP address, nothing conclusive was found, but continued monitoring of the website showed more people using it. The user database filled with new users with different types of authorization levels.

Wanting to know who was accessing the website, we correlated the IP address with the browser User Agent strings they were using. While observing the server, we also noticed we could access PHP session files, which store usernames, passwords, and user settings. The session files did not include the IP addresses for correlation with the network connection.

Since we were able to modify the PHP code to log IP addresses, accessing the website and the JQuery library (Ivan included it in his system) drove us to find a stealthy means—our own OpSec—to allow browsers to connect to our logger. We obtained the PHP session ID by injecting JavaScript into the JQuery file to make a request to a page that looked as if it belonged to Ivan. We also added a hidden PHP script that accepts POST requests and downloads the PHP session file belonging to the user session ID. Finally, we could correlate user connections and IP address.

During our monitoring, we noticed someone logging in as the admin user from a VPN IP address. This admin user also logged in through SSH from a foreign IP address. We knew that one of the admin users was Ivan, but who was the other admin user, logging in through the VPN service?

Because Ivan left his email address and password in the test PHP file, we looked at his email address online. It turns out that Ivan keeps his freelance work nicely ordered in an online folder. When we searched for his recent projects, we found that he was hired by a person who calls himself Anatoly and that Anatoly communicates by email and Jabber.

Searching for Anatoly’s email addresses didn’t return any useful results. However, Ivan’s projects showed a record of his work for Anatoly, revealing that Ivan knows the goals of Anatoly’s operations and does not mind helping Anatoly with his cybercriminal activities. Ivan also stores the work payment details, as well as details of all the domains and servers with their appropriate usernames and passwords.

Having learned all of Ivan’s details, we turned our focus to Anatoly. Who is this enigmatic person, and what does he want? There was no information other than his email address and other account details. Looking at these usernames and passwords, we can see that the accounts for registering domain names and other services had weak passwords, while the accounts used to register servers had strong passwords.

Using passwords recovered from Ivan’s folder allowed us access to the messaging server Anatoly used to get in touch with both his customers and his “employees.” Looking at the Jabber sessions, we found that Anatoly’s Jabber account connected from the same IP address as the original VPN. We were now certain the other admin logging into the server was Anatoly.

To learn what Anatoly was communicating with others, we logged into the messaging server with his handle. Having access to the messaging server’s user database allowed us to obtain the password. Once again, Anatoly used a strong password. While logged in, we attempted to recover his earlier conversations, only to find that Anatoly used good OpSec practices in encrypting the messages, which did not leave any data to recover in his account.

[ Explore TechBeacon's guide to SecOps challenges and opportunities. Plus: Download the 2019 State of Security Operations report. ]

What does this story tells us about OpSec?

Anatoly does a very good job when it comes to OpSec by using an alias, his alternate persona, only for communications with his “contractors.” This alias is not used anywhere else. Anatoly uses a VPN and a virtual machine that can be easily changed and discarded. He lets other people register domains, buy hosting services, and develop systems. He buys pre-made systems and instructs other people to pay his “employees” with their money or a cryptocurrency. He uses strong passwords and doesn’t reuse them. He increases his reputation by building relationships with his cooperators but never shares anything about his personal life.

On the other hand, Ivan has likely never heard of OpSec. He stores his personal email address and passwords in PHP files on a hosted server. His secure programming skills are nonexistent, which allows others to retrieve his password. He stores PII information, passwords, banking details, and more in his email account and reuses passwords. His email account contains so much information someone can easily steal his identity and act on his behalf.

Because Ivan is bad at OpSec and secure programming, he represents a risk to Anatoly. His bad OpSec practices allowed us to discover Anatoly, the mastermind behind the operations, and continue to follow his activities until his first OpSec failure, which will lead us to discovery of his real identity and notification of the law enforcement agencies. One noteworthy question is, How does Anatoly connect to his VPN? Recent changes in foreign legislation—changes that require VPN companies to log user access—may prove to be Anatoly’s final undoing and lead to his discovery by law enforcement.

 

[ Effective SecOps requires staying one step ahead. Get up to speed with this Webinar covering UEBA and MITRE ATT&CK ]