Most popular email programs like Microsoft Outlook, Apple Mail, Thunderbird, etc. have a convenient feature that enables them to remember the email addresses of people that have been emailed. Without this feature people would need to recall email addresses from memory or copy and paste from an address book. This same feature enables hackers to secretly breach networks (in this case for hacking casinos) using a technique that we created back in 2006 and named Email Seeding.
This article explains how we used Email Seeding to breach the network of a well-known and otherwise well protected casino. As is always the case, this article has been augmented to protect the identity of our customer.
Lets begin…
Our initial objective was to gather intelligence about the casino’s employees. To accomplish this, we developed a proprietary LinkedIn tool that uses the name or domain of a company and extracts employee information. The information is compiled into a dossier of sorts that contains the name, title, employment history and contact information for each targeted individual. Email address structure is automatically determined by our tool.
It is to our advantage if our customers use Google apps as was the case with the casino. This is because Google suffers from a username enumeration vulnerability that allows hackers to extract valid email addresses. For example, if we enter [email protected] and the address does not exist then we get an error. If we enter the same address and it does exist, we don’t get an error. Our LinkedIn tool has native functionality that leverages this vulnerability which allows us to compile a targeted list of email addresses for Spear Phishing and/or Social Engineering.
We used this tool to compile a target list for the casino. Then we assembled an offensive micro-infrastructure to support a chameleon domain and its associated services. The first step in this process to register a chameleon domain, which is a domain designed to impersonate a legitimate domain (with SSL certificates and all). Historically this was accomplished by using a now obsolete IDN Homoglyph attack. Today we rely on psychological trickery and influence the tendency of the human brain to autocorrect incorrectly spelled names while perceiving them as correct.
For example, let’s pretend that our casino’s name is Acme Corporation and that their domain is acmecorporation.com. A good chameleon domain would be acmecorporatlon.com or acmceorporation.com, which are both different than acmecorporation.com (read them carefully). This technique works well for longer domains and obscure domains but is less ideal for shorter domains like fedex.com or ups.com for example. We have tactics for domains like that but won’t discuss them here.
There are a multitude of advantages to using a chameleon domain over traditional email spoofing techniques. One example is that chameleon domains are highly interactive. Not only can we send emails from chameleon domains but we can also receive emails. This high-interaction capability helps to facilitate high-threat Social Engineering attacks. Additionally, because chameleon domains are actually real domains they can be configured with SPF records, DKIM, etc. In fact, in many cases we will even purchase SSL certificates for our chameleon domains. All of these things help to create a credible infrastructure. Finally, we always configure our chameleon domains with a catchall email address. This ensures that any emails sent to our domain will be received.
Netragard maintains active contracts with various Virtual Private Server (VPS) providers. These providers enable us to spin up and spin down chameleon infrastructures in short time. They also enable us to spin up and spin down distributed platforms for more advanced things like distributed attacking, IDS/IPS saturation, etc. When we use our email seeding methodology we spin up a micro-infrastructure that offers DNS, Email, Web, and a Command & Control server for RADON.
For the casino, we deployed an augmented version of bind combined with something similar to honeytokens so that we could geographically locate our human targets. Geolocation is important for impersonation as it helps to avoid the accidental face-to-face meetings. For example, if we’re impersonating John to attack Sally and they bump into each other at the office then there’s a high risk of operational exposure.
With the micro-infrastructure configured we began geolocating employees. This was accomplished in part with social media platforms like Twitter, Facebook, etc. The employees that could not be located with social media were located using a secondary email campaign. The campaign used a unique embedded tracker URL and tracker image. Any time the host associated with the URL was resolved our DNS server would tell us what IP address the resolution was done from. If the image was loaded (most were) then we’d receive the IP address as well as additional details about the browser, operating system in use by our target, etc. We used the IP addressing information to plot rough geographic locations.
When we evaluated the data that we collected we found that the Casino’s employees (and contractors) worked from a variety of different locations. One employee, Jack Smith, was particularly appealing because of his title which was “Security Manager” and his linked in profile talked about incident response and other related things. It also appeared that Jack worked in a geographically dissimilar location to many potential targets. Jack became our primary choice for impersonation.
With Jack selected we emailed 15 employees from [email protected]. That email address is a chameleon address, note the “ec” is inverted to “ce”. Jack’s real email address would be [email protected]. While we can’t disclose the content of the email that we used, it was something along the lines of:
“Hi <name>, did you get my last email?”
Almost immediately after sending the email we received a 3 out of office auto-responses. By the end of the next day we received 12 human responses indicating that we had a 100% success rate. The 12 human responses were exciting because chances were high that we had successfully seeded our targets with Jack’s fake chameleon address.
After 4 days we received an email from an employee named Brian with the title “Director of IT Security”. Brian emailed us rather than emailing the real Jack because his email client auto-completed Jack’s email with our seeded address rather than Jack’s real one. Attached to the email was a Microsoft Word document. When we opened the document we realized that we were looking at an incident report that Jack had originally emailed to Brian for comment.
While the report provided a treasure trove of information that would have been useful for carrying out a multitude of different attacks, the document and trust relationship between Jack and Brian was far more interesting. For most customers we’d simply embed malware (RADON) into a document and use macro’s or some other low-tech method of execution. For this customer, given that they were a high-profile casino with high-value targets, we decided to use a zeroday exploit for Microsoft Word rather than something noisy like a macro.
While the exploit was functional it was not flawless. Despite this we were confident that exploitation would be successful. The payload for the exploit was RADON, our home-grown zeroday malware and it was configured to connect back to our command and control server using one three different techniques. Each of the three techniques uses common network protocols and each communicates in using methods that appear normal as to evade detection. The exact details on these techniques isn’t something that share because we use them regularly.
We delivered our now weaponized Microsoft Word document back to Brian with an email that suggested more updates were made. Within 10 minutes of delivery RADON called home and we took covert control of Brian’s corporate desktop.
The next step was to move laterally and infect a few more targets to ensure that we did maintained access to the casino’s LAN. The normal process for doing this would be to scan / probe the network and identify new targets. We wanted to proceed with caution because we didn’t know if the Casino had any solutions to detect lateral movement. So, to maintain stealth, rather than scanning the internal network we sniffed and monitored all network connections.
In addition to sniffing, our team also searched Brian’s computer for intelligence that would help to facilitate lateral movement. Searching was carried out with extreme care as to avoid accessing potential bait files. Bait files, when accessed, will trigger an alarm that alerts administrators and we could not afford to get caught in such early stages. Aside from collecting network and filesystem information we also took screenshots every minute, activated Brian’s microphone, took frequent web-cam photographs and recorded his keystrokes using RADON.
After a few hours of automated reconnaissance, we began to analyze our findings. One of the first things that caught our attention was a screen shot of Brian using TeamViewer. This prompted us to search our keylogger recordings for Brian’s TeamViewer credentials and when we did we found them in short time. We used his captured credentials to login to TeamViewer and were presented with a long list of servers belonging to the casino. What was even more convenient was that credentials for those servers were stored in each server profile so all we had to do was click and pwn. It was like Christmas for Hackers!
Our method from that point forward was simple. We’d connect to a server, deploy RADON, use RADON to gather files, credentials, screenshots, etc. Within 30-minutes we went from having a single point of access to having more control over the casino’s network than their own IT department. This was in large part because our control was completely centralized thanks to RADON and we weren’t limited by corporate polices, rules, etc. (We are the hackers after all).
This was the first casino that we encountered with such a wide-scale deployment of TeamViewer. When we asked our customer why they were using TeamViewer in this manner their answer was surprising. The casino’s third party IT support company recommended that they use TeamViewer in place of RDP suggesting that it was more secure. We of course demonstrated that this was not the case. With our direction the casino removed TeamViewer and now requires all remote access to be handled over VPN with 2 factor authentication and RDP (This type of remote administration software makes Hacking Casinos much easier).
For the sake of clarity, much more work was done for the Casino than what was discussed here. We don’t simply hack our clients, say thank you and leave them hanging. We do provide our customers with detailed custom reports and if required assistance with hardening. With that explained, this article was written with a specific focus on email seeding. We felt that given the current threat landscape this was a good thing to be aware of because it makes for an easy breach.
Hacking Casinos for Fun and Profit
