Cultivating An Online Persona Part 1 - Bypassing Gmail's Phone Verification

Written by noncetonic

Foreword

Cultivating an online persona in the modern era of the internet can be difficult without giving up too much of your own personal information due to the rise of spammers leveraging bots to generate bulk accounts. This leaves the anonymity minded individual with very few options for anonymously registering an account with many services short of paying for services such as recyclable SMS numbers, buying bulk accounts from Phone Verified Account (PVA) shops, or buying SIM cards for one-time use.

Additionally, services are beginning to prompt users to provide photographic proof of their identity making burner SIM cards and other anonymous SMS verification methods only one part of the problem.

The “Cultivating An Online Persona” series will discuss various methods for obtaining access to popular online services while maintaining a user’s anonymity as well as provide readers with an insight into methodologies which can be employed against other services.

Email Addresses Are Important

In a world where your email address is as good as your state ID and act as your gateway to registering for other services, the first step towards cultivating an online persona hinges upon your ability to create an email address which has as little ties to your true identity as possible.

Because of the importance of email addresses, this post will focus on creating a Gmail account while bypassing phone verification.

Bypassing Gmail’s Phone Verification

Why Gmail?

Many readers may wonder why one would even bother attempting to register a Gmail account when there are other services such as ProtonMail which allow users to register for accounts with no personal information. In the opinion of others, myself included, registering for an email account on services such as this inherently gets your persona grouped into a subset of “non-standard” internet denizens. Additionally, due to the popularity of Gmail the chances of a Gmail hosted email address being banned from use for signup or being used as a trigger for secondary anti-spam/anti-bot verification (SABV) is substantially lower.

The Theory

There have been many free bypasses for Gmail phone verification throughout the years including things such as signing up from third-world countries where mobile phones are less common to leveraging mobile phone emulator software such as BlueStacks. While these techniques worked in the past the success rate has dropped substantially causing many to abandon them as viable.

Note: Using mobile phone emulators is an extremely effective way of sneaking by SABV on services primarily accessed via mobile applications such as Instagram.

One technique which has been used successfully is a very simple one in nature is to register for a Gmail account using the youngest age allowable by Google’s adherence to the Children’s Online Privacy Protection Act of 1998.

According to Google’s age requirement policy, in countries outside of South Korea, Spain, and the Netherlands, registrants must be at least 13 years old to create a Google account. As 13 year olds are not expected to have their own mobile phone for phone verification, providing a secondary email for recovery purposes is enough to bypass phone verification. The sweet spot I’ve found for age range is between 13 and 15 in countries where 13 is the minimum age requirement.

The Plan

In order to create our Gmail account we need to satisfy a few requirements:

  • Birth year that puts you between 13 and 15 years old.
  • Email account used to satisfy recovery options

These requirements are easily satisfied and will be discussed before the actual creation of the Gmail account.

Becoming A Teenager

A great resource for all your online persona needs is FakeNameGenerator. Leveraging FakeNameGenerator it’s as easy as clicking the provided link below to generate a birthdate that puts you within our defined age range. All the fun of being a teen again without all the angst and weird body changes!

Generate A Teenage Birthday

FakeNameGenerator

Getting A Recovery Email

There are a lot of places providing email addresses with little to no verification required from a user and a Google search will turn up enough results if you can’t think of one. For the purposes of this post we will use Mail.com. This link will send you straight to their sign-up page. It’s recommended to get your recovery email address to match your desired Gmail address as closely as possible. This isn’t a requirement but it doesn’t hurt in the off chance your registration is checked by an account review process.

Note: As this is the email address that will be used to regain access to your Gmail in case of lockout it is advised to use a unique, strong password if you have reason to believe your account would be targeted for takeover by a third-party.

Recovery Email Signup

Registering With Gmail

And now the section you’ve been waiting for.

  1. Visit the Google Signup Page
  2. Fill out the signup form. Personally I just copy paste the information generated by FakeNameGenerator.
  3. Ensure your Birthday puts you in the appropriate 13-15 year age range.
  4. Leave the Mobile phone field blank.
  5. Provide your recovery email in the Your current email address field. Gmail Account Signup
  6. Click Next step.
  7. Confirm your recovery email by clicking the link provided by Google that will be sent to your provided recovery email address.
  8. Enjoy your new Gmail account.

Note: While using Tor will almost instantly get you flagged, attempting to create multiple Gmail accounts in this way using the same IP address and without clearing your browsing session will often result in the registration getting flagged by SABV and causing you to get the phone verification prompt.

Closing

Now that you’ve got your own real-life verified Gmail account the world is your oyster. The next article in this series will cover some of the services you can use your fake persona with to start creating a believable online identity.


Leveraging Application Verifier for Function Hooking and Persistence

Written by actae0n

Introduction to Application Verifier

Function hooking is a powerful tool for attackers. The ability to inspect and modify data structures as they’re passed between functions within a program gives an attacker lots of options for session riding, credential theft, parameter modification, etc. We’re going to take a look at an excellent tool that is provided to us by Microsoft called Application Verifier, which can be leveraged to perform hooking(and persistence) in a trivial, yet powerful manner by letting us run code in the context of an arbitrary unmanaged(native) application.

The MSDN page describes AppVerifier as such:

Application Verifier assists developers in quickly finding subtle programming errors that can be extremely difficult to identify with normal application testing. Using Application Verifier in Visual Studio makes it easier to create reliable applications by identifying errors caused by heap corruption, incorrect handle and critical section usage.

Application Verifier loads a particular Verification Provider into a process as it starts up. This provider, which comes in the form of a DLL, should contain the tests that are to be run in the context of the application being tested. These “tests” can be arbitrary. The provider is loaded at application startup, right after NTDLL.dll; Because of this, we won’t have access to managed code segments in our attack code because we cannot load the CLR (Common Language Runtime, AKA .Net’s execution environment) this early. For most things, this isn’t an actual problem, but it’s good to know.

So, we can load code into any application as it starts using a mechanism provided by the operating system? LD_PRELOAD anyone? Let’s see how we can leverage this.

Overall, the process of getting our code launched is as follows:

  • We create a DLL which serves as the Verification Provider. This DLL is supposed to run routines that verify the application that it is loaded into. It will contain our function hooks and other code. We will drop this into %windir%\System32\ or %windir%\SysWoW64\ (depending on the bitness of the target application).
  • We create a registry key with a few subvalues which sets a few flags (to enable Application Verifier in the right mode) and detailing the name of the library which will serve as the verification provider (our malicious DLL).
  • When the application starts (before other libraries are loaded, with the exception of NTDLL) our Verification Provider will be loaded and execute its code. The load reason will not be THREAD_ATTACH or PROCESS_ATTACH as it typically is when a DLL is loaded. The value of fdwReason in this case is 4, which an existing symbol does not exist for. We will just define as VERIFIER_LOADED ourselves for readability and convenience.

Note that this method requires administrator privileges (a UAC bypass should happen before installing the verification provider and its accompanying registry entries), as we’re writing to HKLM and performing a privileged copy into System32 or SysWow64.

Demonstration

For the demonstration of these capabilities, we’re going to inspect and log POST requests made by Firefox by hooking the PR_WRITE function. This will give us access to the data as it’s being sent, just before it becomes encrypted with TLS and sent over the network.

Details on PR_WRITE and other functions in the Netscape Portable Runtime can be found here.

You can parse these requests with regular expressions to extract usernames and passwords from POST requests sent to login pages, for example. These siphoned passwords or sensitive requests can be loggedto a 3rd party server. I won’t go over writing the regular expressions or reporting aspect, as this article is meant to focus on the deployment and implementation of the hook. When the function is called, our code will execute before the real function and we will be able to inspect or modify the data before forwarding it to the real function. For PR_WRITE, the data being written to the specified file descriptor(fd) is stored in the buf parameter.

The Code

Sometimes you’ll be working with mostly opaque code (no source available) and have to deal with reverse engineering to determine structure types and contents, function prototypes, etc. This can suck. In this case howerver, the code we’re looking for (the Netscape Portable Runtime headers) is available for inspection and copypasta. We’ll be using their headers to define the structures we’re accessing.

Note that when compiling this DLL, its bitness must match the target application. You must also disable the CLR and set the entrypoint to DllMain. Not doing so will cause the verifier to fail to load. If you decide to implement any assembly routines to be run, you should also then disable optimizations. Visual Studio makes doing these things fairly easy via tweaking project settings.

With our DLL compiled, we just copy it into the correct directory like so:

DLL Dropped

Then create the key firefox.exe under HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Image File Execution Options\. Add the following values:

Registry Values

Then launch Firefox from WinDbg.

Firefox Before Debug Resume

Press g to release the breakpoint and let Firefox continue execution, then navigate to a website. I’ll go to Google.com; We can see in the window that our traffic that is passing through PR_WRITE is being logged successfully.

A Test Request

Now let’s do a test to see if we really do have access to sensitive traffic. I’ll try to log into Twitter (with fake credentials of course).

Logging into Twitter

Now let’s inspect our traffic log file and search for these values:

Found It!

Awesome. The selection in question is also trivial to write a regular expression for, so you could write a version of this hook that excludes all of the “junk” traffic and only reports the username and password values with a regular expression filter.

With Respect To Persistence

Instead of installing a function hook, you could simply use this code execution point as a springboard to launch some other component of your malware. You can still use the DLL_PROCESS_ATTACH event as normal, and it’s subject to all the same restrictions as it typically is.

Sources: