What is Reconnaissance

When an attacker first identifies an organization or individual they wish to target, they first start by gathering information that would help make an attack more effective...this process is called reconnaissance. Reconnaissance comes in a number of flavors:

• LinkedIn might help attackers identify employees and critical technology positions (e.g. developer, system administrator, Site Reliability Engineer (SRE), security engineer, etc.)
• LinkedIn and IT Job Postings will commonly indicate the technologies used by an organization (Microsoft365/Google Workspace, Okta/Azure AD/Ping Identity, CyberArk/SailPoint/etc.)
• Organizational Website(s), Portals, and Online Documents can expose a wide variety of information about an organization - leadership, mergers/acquisitions/divestitures, organizational units, physical locations or branches, and much more.
• Google and Github "Dorking" may identify sensitive documents and information your organization or its employees have accidentally exposed to the public internet. This may include passwords or "access keys", which may be highly sensitive.
• DNS Records associated with organizational domains
• Unauthenticated Reconnaissance and Password Spraying Tools

During the reconnaissance process, 

Even during the golden age of "on-premises" computing, where organizations maintained their own infrastructure - it was commonly possibly to attack e-mail or VPN login from the external int

1. Attacker identifies valid domain for organization in Azure AD using Oh365UserFinder.
2. Attacker identifies e-mail address pattern using a known valid employee using hunter.io, corporate website, LinkedIn, or other source.
3. Attacker scrapes LinkedIn and other websites to identify employee names.
4. Attacker generates list of potential e-mail addresses from web scraping.
5. Attacker tests potential e-mail addresses against Oh365UserFinder.
6. Attacker generates list of potential e-mail addresses based on most common names using identified naming pattern.
7. Valid Results are fed into Quiet Riot - which identifies AWS root account credentials.
8. Quiet Riot returns valid IAM Root Users from list of e-mail addresses.
9. Attacker targets root account e-mail for phishing. If attacker can gain control of AWS session - great. If not, attacker can attempt to gain control of inbox.
10. Once inbox is controlled, if MFA not set then Root Account Takeover can be performed via e-mail.
11. If Root Account MFA configured, attacker can take over via e-mail and phone # compromise.