Overview

T1591 (Gather Victim Org Information) describes adversary reconnaissance activity aimed at collecting details about a target organization — including its structure, business units, key personnel, roles, and internal processes. Attackers use this intelligence to sharpen later-stage operations such as spear-phishing, business email compromise, supply chain attacks, and social engineering campaigns tailored to specific employees or departments.

Because this technique frequently occurs entirely outside your perimeter — on LinkedIn, company websites, data breach repositories, and job boards — direct detection is difficult. However, when adversaries interact with internal systems to harvest org data (such as exporting user directories, scraping HR portals, or bulk-querying identity platforms), those actions leave audit trails. Every security team must instrument those systems and monitor for bulk data exports or unusual enumeration of user and organizational data, because a successful reconnaissance phase dramatically increases the probability of a targeted intrusion succeeding.

Attacker Perspective

Adversaries treat organizational reconnaissance as foundational work that makes every subsequent attack more precise and more likely to succeed.

• User directory harvesting via admin consoles: An attacker with compromised admin credentials logs into Bitbucket Server or Jira and uses the built-in export function to download a full CSV of usernames, email addresses, group memberships, and permission levels — immediately mapping who has privileged access to which repositories.
• LDAP/AD enumeration with BloodHound: After gaining a foothold, the attacker runs SharpHound.exe -c All --zipfilename loot.zip to enumerate Active Directory users, groups, OUs, and trust relationships, building a complete org chart and identifying the shortest path to Domain Admin.
• LinkedIn and OSINT scraping with tools like theHarvester: Before ever touching the target network, the attacker runs theHarvester -d targetcorp.com -b linkedin,google,bing -l 500 to collect employee names, job titles, email formats, and technology stack clues from public sources.
• Microsoft 365 / Azure AD user enumeration: Using tools like AADInternals or the Get-AzureADUser PowerShell cmdlet, attackers enumerate all users, their UPNs, assigned roles, and MFA status from the tenant, identifying high-value targets such as Global Admins or Finance leads for follow-on phishing.

This technique is attractive precisely because most of it is low-risk for the attacker — passive OSINT carries near-zero chance of detection, and even active internal enumeration is often lost in the noise of legitimate admin activity.

Detection Strategy

Required Telemetry

• Bitbucket Server Audit Logs (Advanced level required): In Bitbucket Server administration, navigate to Admin → Audit Log → Configure and set the logging level to Advanced. Without this, user export events are not recorded. Logs should be forwarded to your SIEM via syslog or a log shipper (Filebeat, Splunk UF). Key fields: auditType.category, auditType.action, actor.name, clientAddress, timestamp.
• Azure Active Directory / Entra ID Audit Logs: Enable Diagnostic Settings in the Azure Portal to stream AuditLogs and SignInLogs to your SIEM or Log Analytics Workspace. Captures bulk user enumeration, role assignment reads, and group membership queries. Key fields: operationName, initiatedBy.user.userPrincipalName, targetResources, result.
• Active Directory (Windows Event Logs): Enable Account Management and Directory Service Access auditing via Group Policy: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration. Relevant Event IDs: 4798 (user's local group membership enumerated), 4799 (security-enabled local group membership enumerated), 4662 (operation performed on AD object — requires SACL on the directory). Forward via Windows Event Forwarding (WEF) or a SIEM agent.
• Windows PowerShell Script Block Logging: Enable via GPO at HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Generates Event ID 4104 in the Microsoft-Windows-PowerShell/Operational log. Captures cmdlets like Get-AzureADUser, Get-ADUser, and BloodHound's SharpHound invocations.
• Microsoft 365 Unified Audit Log (UAL): Must be explicitly enabled in the Microsoft Purview compliance portal (Audit → Start recording user and admin activity). Stream to Sentinel via the Microsoft 365 connector or export via Search-UnifiedAuditLog. Captures bulk user directory reads, role enumeration, and admin center exports. Key fields: Operation, UserId, ObjectId, RecordType.
• Web/Proxy Logs: Capture outbound HTTP/S traffic to known OSINT aggregator sites, LinkedIn, data broker APIs, and job posting platforms. Key fields: src_ip, dst_domain, url, user_agent, bytes_out. This helps detect insider-driven OSINT scraping from corporate infrastructure.
• HR / Identity Platform API Logs (e.g., Workday, Okta, ServiceNow): Enable API access logging in each platform. Focus on bulk GET /users or GET /groups API calls, especially those returning large result sets or executed by service accounts outside normal business hours.

Key Indicators

• Bitbucket user/permission export events: In Bitbucket audit logs, look for auditType.action values of "User permissions export started", "User permissions exported", "User details export started", or "User details exported". Any single export event warrants review; a failed export followed immediately by a successful one is especially suspicious (indicates trial and error).
• Bulk AD user enumeration via PowerShell: In Event ID 4104 logs, search for script blocks containing Get-ADUser -Filter *, Get-ADGroupMember, or Get-ADOrganizationalUnit. Legitimate admin scripts typically target specific OUs or users, not wildcard queries across the entire domain.
• BloodHound/SharpHound execution: In process creation logs (Sysmon Event ID 1 or Windows Event ID 4688 with command-line auditing enabled), look for CommandLine containing SharpHound, -c All, --zipfilename, or the default output pattern *_BloodHound.zip. Also watch for BloodHound.exe or bloodhound-python in process names.
• Abnormal volume of AD object reads (Event ID 4662): A single non-admin account generating hundreds of 4662 events against User or Group objects within a short window (e.g., more than 200 events in 5 minutes) is a strong signal of automated enumeration.
• Azure AD bulk user reads: In AAD Audit Logs, operationName = "List users" or "Get group members" executed by a user account (not a service principal running a known sync job) with a targetResources count significantly above baseline is suspicious. Flag especially if the initiating UPN is from an external or recently-created account.
• M365 UAL bulk directory operations: Look for Operation = "UserLoggedIn" followed rapidly by Operation = "SearchQueryPerformed" or admin-level operations like "Get-User" executed in a loop. The field RecordType = 8 (AzureActiveDirectory) with high-frequency reads from a single session is notable.
• Outbound scraping from corporate IP to OSINT sources: In proxy logs, flag dst_domain matching patterns like linkedin.com, hunter.io, rocketreach.com, intelx.io, or haveibeenpwned.com with bytes_out significantly higher than the organizational baseline, or with a user_agent consistent with automation tools (e.g., python-requests, curl, Go-http-client).

Detection Logic

Rule 1 (Broad — High Sensitivity): Bitbucket User or Permission Export Activity
IF log_source = "bitbucket_audit" AND auditType.category = "Users and groups" AND auditType.action IN ("User permissions export started", "User permissions exported", "User details export started", "User details exported", "User permissions export failed", "User details export failed") THEN alert(severity=medium)

This catches any attempt to bulk-export user or permission data from Bitbucket. Expected alert volume is low in most environments — exports are an infrequent administrative action. A failed export immediately followed by a successful one from the same actor.name or clientAddress should be escalated to high severity.

Rule 2 (Broad — High Sensitivity): High-Volume AD Object Enumeration
IF log_source = "windows_security" AND EventID = 4662 AND ObjectType IN ("user", "group", "organizationalUnit") AND count(EventID) BY SubjectUserName, timewindow=5min > 200 AND NOT SubjectUserName IN [known_ad_sync_accounts, dc_computer_accounts] THEN alert(severity=medium)

Catches automated directory enumeration tools querying large numbers of AD objects rapidly. Sync accounts and DC machine accounts must be excluded to keep volume manageable. Tune the threshold based on your environment's baseline — start at 200 and adjust after baselining for one week.

Rule 3 (Medium Precision): PowerShell Wildcard AD Enumeration
IF log_source = "powershell_scriptblock" AND EventID = 4104 AND ScriptBlockText MATCHES ("Get-ADUser\s+-Filter\s+\*" OR "Get-ADGroupMember" OR "Get-AzureADUser\s+-All\s+\$true" OR "SharpHound" OR "Invoke-BloodHound") AND NOT ParentProcessName IN ["expected_admin_tools.exe"] AND NOT UserName IN [approved_admin_service_accounts] THEN alert(severity=high)

Targets specific cmdlets and tooling known to be used for org-structure reconnaissance. False positive rate is low if service accounts are properly baselined. SharpHound matches should always be treated as high confidence.

Rule 4 (High Precision): Automated Outbound OSINT Scraping from Corporate Hosts
IF log_source = "proxy_logs" AND dst_domain IN ["hunter.io", "rocketreach.com", "intelx.io", "snov.io", "apollo.io"] AND user_agent MATCHES ("python-requests|curl|Go-http-client|libwww-perl|scrapy") AND src_ip IN [corporate_ip_ranges] THEN alert(severity=high)

Catches insider-driven or malware-driven automated scraping of commercial OSINT and email-finding tools from inside the corporate network. Legitimate employee use of these sites via a browser will have a standard browser user-agent and can be excluded if needed, though policy may prohibit the activity regardless.

Tuning Guidance

• Scheduled HR or compliance exports from Bitbucket: Some organizations run automated compliance audits that export user permission data on a schedule. Identify the service account or scheduled task responsible and exclude its actor.name and the specific clientAddress it runs from. Document this exclusion with a change ticket reference so it is reviewed periodically.
• Azure AD Connect and directory sync accounts: These generate extremely high volumes of directory read operations by design. Exclude their specific service principal IDs or UPNs (e.g., Sync_*@tenant.onmicrosoft.com) from AD enumeration rules. Never exclude them globally — scope the exclusion to the specific operation types they use.
• IT admin PowerShell scripts: Sysadmins legitimately use Get-ADUser -Filter * during audits. Build a baseline of which accounts run these commands, from which hosts, and at what frequency. Exclude known admin accounts only when operating from their designated jump hosts (e.g., UserName IN [admin_accounts] AND src_host IN [jump_servers]), not unconditionally.
• Security tools performing their own enumeration: Vulnerability scanners, PAM solutions (CyberArk, BeyondTrust), and SIEM connectors may enumerate AD or Azure AD as part of normal operation. Identify their service accounts and source IPs and create named exclusions — do not use broad exclusions like "all service accounts."
• Recruitment team use of OSINT platforms: HR and recruiting staff legitimately access LinkedIn, Apollo.io, and RocketReach from corporate devices. Exclude their user identities from proxy-based OSINT scraping rules, but retain alerting on automation user-agent strings even for those users, as legitimate browser use won't trigger those patterns.

When the Alert Fires: Investigation Steps

1. Verify the alert is real and retrieve the raw event. Pull the original log entry directly from your SIEM using the event ID or timestamp from the alert — confirm the auditType.action, actor.name, clientAddress, and timestamp fields are present and unambiguous. Do not proceed on a parsed alert alone; always validate against the raw source log in Bitbucket audit, the Windows Security event log, or the AAD Audit Log.
2. Identify the account and host involved, and flag if privileged. Look up the actor.name or SubjectUserName in your identity provider (Active Directory, Okta, Azure AD) to determine the account type, group memberships, and assigned roles. If the account holds admin, DevOps, or HR roles, escalate priority immediately — privileged account involvement indicates either insider activity or a compromised high-value account.
3. Establish the full activity timeline for that account in the preceding 24–72 hours. Query your SIEM for all events associated with the triggering account across all log sources (authentication logs, Bitbucket audit, AAD sign-in logs, VPN logs) for the 72 hours before the alert. Look for anomalies such as logins from unusual geographies, new device registrations, or access to systems outside the account's normal baseline — these indicate the account may have been compromised before the export occurred.
4. Examine the export itself — what data was taken and how much. If the alert was a Bitbucket export, check whether the export completed (auditType.action = "User details exported") or failed. If it completed, determine the scope: was it a full export of all users, or scoped to a specific project or group? For AD enumeration events, calculate the total count of 4662 events in the session to understand how much of the directory was walked.
5. Check for data exfiltration following the export. Query proxy and firewall logs for outbound connections from the source host or account session within 30 minutes of the export event. Look for large outbound transfers (bytes_out significantly above baseline), connections to file-sharing services (Dropbox, Google Drive, Mega.nz), or connections to IPs/domains with no prior history in your environment. Cross-reference destination IPs against threat intelligence feeds in your SIEM.
6. Search for lateral movement originating from the same host or account. In your SIEM, query for authentication events (Windows Event ID 4624 logon type 3, or SSH logins) where the SubjectUserName or source IP matches the investigated account or host, occurring after the export timestamp. Also run a Sysmon or EDR query for new process creation or network connections from that host targeting other internal systems — this identifies whether the reconnaissance is part of a broader intrusion in progress.
7. Make the escalation decision based on evidence weight. Escalate to a confirmed incident if you observe any of the following: the export was completed by an account with no legitimate business need for that data, the account shows signs of compromise (impossible travel, new MFA device, unusual login time), data was transferred externally following the export, or lateral movement is detected. Treat the alert as likely benign if the actor is a known admin running a documented compliance task, the activity matches a scheduled job, and no post-export anomalies are present — but document your reasoning and close with evidence, not assumption.

Response Playbook

Containment

• Isolate the host if an active intrusion is suspected: If EDR is deployed (CrowdStrike, Defender for Endpoint, SentinelOne), use the platform's network containment feature to isolate the host from the network while keeping it powered on for forensic memory capture. Do not shut it down — volatile memory may contain credentials, encryption keys, or malware artifacts.
• Disable the implicated user account immediately: In Active Directory, run Disable-ADAccount -Identity [username] or use the AD Users and Computers console. In Azure AD / Entra ID, set accountEnabled = false via the portal or Set-AzureADUser -ObjectId [UPN] -AccountEnabled $false. For Okta or other IdPs, use the admin console to suspend the account. Notify the account owner's manager before doing so if time permits, but do not delay containment waiting for approval.
• Revoke all active sessions and tokens for the account: In Azure AD, use Revoke-AzureADUserAllRefreshToken -ObjectId [UPN] or the Entra ID portal (Users → [User] → Revoke Sessions). In Okta, clear all sessions from the admin console. For on-premises systems, force logoff of any active RDP or console sessions using logoff [session_id] /server:[hostname].
• Block identified malicious IPs and domains: If investigation revealed outbound connections to suspicious destinations, push blocking rules to your perimeter firewall and DNS filtering solution (Umbrella, Zscaler, Windows Defender SmartScreen policy) immediately. Use threat intelligence context to avoid blocking legitimate CDN IPs that may cause collateral damage.
• Restrict Bitbucket or platform export permissions pending investigation: If the export occurred through an application like Bitbucket, temporarily revoke the export permission from all non-essential accounts at the group policy level within the application until the investigation concludes. Document the change and set a review date.

Eradication

• Search for and remove any tools dropped on the host: Using your EDR or a forensic tool (Velociraptor, KAPE), search the host for known enumeration tools: SharpHound.exe, BloodHound, ADExplorer.exe, ldapdomaindump, or any ZIP files with names matching BloodHound output patterns (e.g., *_BloodHound.zip). Hash any discovered files and compare against VirusTotal before deletion.
• Audit and remove any persistence mechanisms added: Check scheduled tasks (schtasks /query /fo LIST /v), new services (sc query type= all), run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), and startup folders. If the account was used remotely, also check for new SSH authorized keys, new local admin accounts, or changes to sudoers on Linux systems.
• Reset credentials for all affected accounts: Force a password reset for the implicated account and any other accounts that authenticated from the compromised host during the suspicious period. If the account is a service account with a hardcoded password in scripts or configuration files, coordinate with the owning team to rotate it in all locations simultaneously to avoid service disruption.
• Rotate any secrets, API keys, or tokens exposed during the incident: If the compromised account had access to Bitbucket repositories, CI/CD pipelines, or cloud IAM roles, audit for hardcoded secrets or access tokens in any repositories the account could read. Rotate any exposed secrets and audit CloudTrail, AAD sign-in logs, or equivalent for evidence those credentials were used.
• Verify lateral movement targets are clean: For every internal system the compromised account authenticated to during the investigation window, run a targeted EDR sweep or check the system's own audit logs for suspicious process creation, new accounts, or file changes. Do not assume systems are clean without verification.

Recovery

• Re-image the host if confidence in cleanliness is low: If forensic analysis cannot definitively rule out a persistent implant, re-image the host from a known-good baseline rather than attempting manual cleanup. Restore data from a pre-incident backup snapshot and validate its integrity before returning the host to service.
• Re-enable the user account only after full verification: Before re-enabling the account, confirm that all persistence mechanisms have been removed, credentials have been rotated, and MFA has been re-enrolled on a verified device. Walk the account owner through a security briefing on phishing awareness if social engineering is suspected as the initial access vector.
• Monitor the affected host and account intensively for 72 hours post-remediation: Create a temporary high-sensitivity watchlist rule in your SIEM that alerts on any event from the previously compromised host or account for the next 72 hours, regardless of severity. This catches re-compromise attempts or persistence mechanisms that were missed during eradication.
• Review and tighten export permissions across identity and dev platforms: Use the incident as a driver to audit who has permission to export user data from Bitbucket, Azure AD, HR systems, and other platforms. Apply least-privilege principles and ensure export actions require a second approval or are restricted to named admin accounts with documented business justification.
• Document the full incident timeline and update detection rules: Write a complete incident timeline from first evidence to containment, including all IOCs discovered (hashes, IPs, account names, tool names). Feed new IOCs into your threat intelligence platform and update your SIEM detection rules to include any new patterns observed. Conduct a brief post-incident review with the SOC team to identify detection gaps and close them before the incident record is archived.