How to Purge Google and Start Over – Part 1
A Tale of Blue Destroying Red
Let me start by sharing a story about a fairly recent red team engagement against a highly-secured technical customer that didn’t end so well for me. Their SOC was well-equipped with sophisticated in-house anomaly detection tools, incredible visibility across the organization, and a tenacious incident response team. They were a Google customer and leveraged G Suite to handle their cloud-based business applications which immediately made me excited. I’ve spent a considerable amount of time researching and learning how to weaponize Google products to target organizations, so I immediately had a number of different attack-path ideas ready and started on the journey.
After my team and I successfully compromised credentials and bypassed two-factor using CredSniper, we immediately started laterally pivoting through Google applications looking for the typical company data. This is when we first learned about the anomaly detection systems because they were leveraging Google Groups to send distribution emails to technical teams which contained interesting security alerts and crontab command-line logs in the archives. Needless to say, they were heavily invested in Google technologies, which is why this story is important. It wasn’t long before the customer, with the help of Google, identified our authentication activity as suspicious. Whether it was because of a device that was never seen before, a location completely different
The Power of Collaboration
You might be asking yourself why this background story is relevant. Within those 24 hours, Google SOC was able to track and correlate all my burner accounts, phones, and API tokens then suspend the accounts. This included personal and work accounts. Making matters worse, they also went ahead and reconciled the indicators of compromise to my work account, suspending it citing a violation of the terms and service. Our system admin re-enabled it the next day and they re-suspended it while suspending the system admin ability to re-enable it. Were they wrong? Probably not. Would I have done the same thing? More than likely. Trust me, Google’s ability to track and correlate accounts is very, very good. Over the next few days, I realized the extent of the damage. I missed emails from customers in which Google bounced back, I was unable to access any of the resources where my Google account was the authenticated identity, my work calendar wasn’t accessible leaving me without knowing my daily agenda, and I couldn’t even burn the down-time watching my YouTube backlog! (LOL)
If the fall-out had happened at the organizational account level then that would have meant the entire business could have come to a screeching halt. Eventually, we were able to work with our customer and Google to resolve the misconceptions and alleged violations of the terms of service but not before I learned a valuable lesson. Over the next few weeks, my wife and I continually had authentication issues where Google account sessions across all devices would randomly require re-authentication. Laptops, televisions, thermostats, tablets, and more. It may have just been a timing fluke but the reality was unsettling. Were our home IP addresses flagged as malicious in Google systems?
Raising Eyebrows
The ability of a technology giant to dominate every facet of my work life with a flip of a switch and at the discretion of their employees could have long-lasting implications within our industry if abused. I was informally provided information from the customer that Google SOC gave them links to Beau Bullock and I’s calendar event injection research, which was the initial access vector. This explains that those triaging within Google SOC knew the technique, that Black Hills Information Security was a pentesting company, that I was a tester at the company, and that the origin of the technique was me. While the customer provided BHIS with authorization to include third-party accounts in-scope, Google doesn’t seem to have a transparent pentesting approval process that informs them of activity but they have afforded general approval in their Security and Compliance page under the Penetration Testing section.
So did Google have enough information to limit the impact on my account? Even if they did, could they have managed this dilemma in a better way? Did I actually violate the Terms of Service? After all, they did agree that no TOS was violated before reinstating my account but it took an incredible amount of back and forth between all affected parties. The only two stipulations in Google’s requirements for penetration testing is abiding by the Acceptable Use Policy and that their Google Cloud Terms of Service are not violated. Obviously violating anything anywhere can result in a ban of everything everywhere.
This ambiguity is just one thing that every tester needs to be aware of and hopefully is addressed in the very near future. In fact, this is an issue that all testers everywhere need to be aware of when testing any cloud-based services. We are in uncharted territory in respect to cloud testing. Many vendors have a policy that we are never to test their core services. Others, are much better to work with. We are using this series as a cautionary tale to other testers and companies.
Begging the Question
With the rise of de-platforming, terms of service violations, and vague interpretations; what could this mean for the future of personal accounts that violate much more unclear terms of service? I’m not waiting to find out. Check out part 2 where I systematically de-platform myself by purging Google from every facet of my personal life, my family, and all of my devices. The journey was an incredible undertaking that required extensive research and planning to avoid a number of subtle issues that could result in major headaches.
How to Purge Google and Start Over – Part 2
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
