Disclaimer: The industry type and specific business domain of the target organisation have been purposefully obscured in this case study to maintain client privacy and honour contractual obligations. All names, email addresses and identifying details have been fabricated or altered. The information shared here is strictly for educational purposes -- to illustrate how phishing and social engineering campaigns are planned and executed in a controlled red team engagement and how organisations can better defend against them.
This is Part 2 of the multi-part series. If you have not read Part 1, we recommend starting there for context on the engagement background, OSINT and initial vishing operations. Read Part 1 here.
Phishing and Social Engineering Campaign
Engagement Context
By this stage of the engagement, we had already established a foothold through the vishing operations detailed in Part 1. Organisation Alpha's environment was well-defended -- they used Microsoft Office 365 with Exchange Online Protection (EOP), the cloud-based filtering service that protects against spam, malware and standard phishing attempts.
We knew that a traditional mass-phishing approach would fail. EOP, combined with Alpha's security-aware culture (forged through five previous red team engagements), meant that any lazy or template-driven phishing attempt would be flagged, quarantined, or reported.
Success required pragmatic planning and surgical execution.
Campaign Infrastructure and Preparation
Target Email Address Enumeration
Before launching any phishing emails, we needed a precise target list. This was assembled through two methods:
Passive Reconnaissance: As detailed in Part 1, we had already enumerated a significant number of staff email addresses through OSINT -- LinkedIn scraping, email format validation and public directory analysis.
Internal Application Access: After compromising our first staff account (through the vishing operations in Part 1), we gained access to Organisation Alpha's internal business applications via O365 Single Sign-On (SSO). One of these applications included an internal phonebook -- a staff directory with full contact details, department listings and direct phone numbers.
While we could have queried the O365 Global Address List (GAL) for staff details, the internal phonebook was significantly faster and provided richer data -- including office locations, reporting lines and role descriptions.
Using a wildcard query on the phonebook, we were able to enumerate over 1,900 staff contact records paginated across nearly 200 pages. We systematically extracted the entire directory -- names, email addresses, office locations, job titles and department affiliations. This gave us a comprehensive, verified target list far beyond what OSINT alone could provide and allowed us to cross-validate the data gathered during the earlier reconnaissance phase.
Server Setup: Cloning Organisation Alpha's Login Portal
The phishing infrastructure required setting up a credential harvesting website that would be indistinguishable from Organisation Alpha's legitimate login experience.
During the reconnaissance phase, we identified that several of Alpha's externally exposed business applications were integrated with O365 Single Sign-On. This meant employees were accustomed to seeing the same SSO login page across multiple internal applications.
We cloned the primary SSO hub login page -- the portal employees used daily to access internal tools. The cloned page was hosted on multiple web servers with various domain names, each selected based on the context and pretext of the specific phishing scenario.
Additionally, we set up a secondary collection page designed to passively harvest technical details from anyone who visited -- device type, operating system, browser version and IP address. This intelligence was used to refine our targeting and understand the technical environment of individual targets.
Email Template Crafting
One of the most critical preparation steps was creating phishing emails that would be indistinguishable from legitimate internal communications.
Having already compromised a staff member's account, we had access to:
- Multiple email signature styles used across different departments
- Internal email formatting conventions (fonts, colours, footer disclaimers)
- The tone and language typical of internal IT and administrative communications
We used these signatures and conventions to craft multiple email templates, each with a different context and pretext tailored to specific target groups. Every template was designed to feel routine and expected -- never urgent or alarming in a way that might trigger suspicion in security-trained staff.
Orchestrating the Campaign: Precision Over Volume
We deliberately avoided the traditional phishing approach of mass-emailing the entire target list. Organisation Alpha's staff had been through security awareness training and a sudden influx of similar emails would almost certainly trigger reports to the IT security team.
Instead, we adopted a phased, surgical approach:
Phase 1 -- Canary Targets: We handpicked a small group of initial targets from our contact list. These were carefully selected based on their role, department and assessed likelihood of engagement. The primary goal was not credential capture -- it was intelligence gathering:
- Did the emails reach their inbox or land in junk?
- Were any emails flagged or reported?
- What was the target's response behaviour?
We obtained this feedback by social engineering the targets directly -- calling them under pretext and casually confirming whether they had received "the IT migration email" we had sent.
Phase 2 -- Refined Targeting: Based on the Phase 1 feedback, we adjusted our email templates, sender domains and delivery timing. We identified which approaches bypassed EOP filtering and which were quarantined.
Phase 3 -- Combined Arms: Through testing, we confirmed that many standard phishing techniques would either get blocked or land in junk folders. Given the time-bounded nature of the exercise, we maximised success by using a combination of social engineering (phone) and phishing (email) on multiple targets simultaneously. In some cases, social engineering alone was sufficient to obtain credentials or sensitive information without any phishing email at all.
Attack Narratives: Account Compromises
The following sections detail specific attack scenarios where we achieved full or partial success. All names and identifying details have been anonymized.
Case 1: "Sarah Chen" -- Full Account Compromise via SE + Phishing
Date: Week 4 of engagement
The first staff account compromised through the phishing campaign belonged to a mid-level employee in the operations department. The RT member compromised her domain credentials using a combination of social engineering and phishing.
The Approach:
The RT member called Sarah posing as IT support, using the name of a real helpdesk team member (identified during earlier reconnaissance). The pretext: her account had not been correctly migrated during the recent system migration, which could cause login failures in the coming days.
We managed to convince her that immediate action was required and she agreed to follow our instructions. She gave us an appointment time for a follow-up call.
Email Delivery Challenge:
We sent her a phishing email containing our credential harvesting link. The email landed in her junk folder -- exactly the scenario we had anticipated with EOP filtering. However, because we were already on a call with her, we told her it was a known O365 error and convinced her to:
- Move the email from junk back to her inbox
- Mark the sender as safe (whitelisting our phishing domain)
Establishing a Remote Session:
Rather than simply asking her to click a link (which would feel suspicious), we took a more sophisticated approach. We convinced her to join a video chat session so that we could "remotely configure her system" -- mimicking the standard IT support workflow she was accustomed to.
She accepted the video call invitation. We requested remote access to her desktop, but she did not have the necessary permissions on her system to grant it. Adapting in real-time, we asked her to share her screen instead -- achieving the same objective through a different vector.
Intelligence Harvested Through Screen Sharing:
With her screen visible to us in real-time, we guided her navigation and captured:
- Email inbox contents -- including internal communications, project updates and confidential attachments
- SharePoint and OneDrive files -- we convinced her to browse through document libraries, revealing internal file structures, project directories and sensitive operational documents
- Internal directory information -- we had her query the GAL for specific departments (particularly finance), capturing org charts, direct contact numbers and reporting structures that would fuel our next wave of targeting
Credential Capture:
By this point, we had established significant trust. Rather than risking the phishing email being flagged again, we sent our credential harvesting URL directly via the video chat window -- completely bypassing O365 email filtering.
We convinced her to log in using that URL. When she entered her credentials, they were captured by our harvesting page.
Bypassing Two-Factor Authentication:
When we attempted to use her credentials, the account was protected by Two-Factor Authentication (2FA). A verification code was sent to her mobile number.
Since we were still on the call with her, we told her that we had generated the code as part of the migration process and she needed to read it back to us to complete the setup. She complied.
We also selected "Don't ask again for 30 days" on the 2FA prompt -- ensuring we could access her account for an extended period without needing additional codes.
After gaining full access, we concluded the session by telling her the migration was successful. We then used her account to query SharePoint, OneDrive and internal applications for further intelligence.
Evidence captured: Phone call recording, video chat recording, screenshots of all access.
Case 2: "Mark Davidson" -- Full Account Compromise via Pure Social Engineering
Date: Week 4 of engagement
The second account was compromised using social engineering alone -- no phishing email was required.
The Approach:
Same pretext as Case 1 -- the RT member posed as IT support and informed Mark that his account needed migration attention. However, instead of directing him to a phishing page, we used the O365 password reset flow as our attack vector.
The Attack Chain:
- We initiated a password reset for Mark's account through the O365 self-service portal
- O365 sent a validation code to his registered phone number
- We told Mark he would receive a code on his phone, claiming that "our system generated it" as part of the migration
- He provided the code and we completed the first verification step
- As a second step, Microsoft Authenticator prompted him to approve the password reset on his phone
- We convinced him to approve it
- We successfully reset his password
Upon reset, he received an automated password change confirmation email from Microsoft. We had to think on our feet -- we told him that "our system sent that email automatically" and it was part of the standard migration process. We provided him with the new password we had set and told him he could change it after one hour, otherwise the migration would fail and we would have to repeat the process.
The one-hour window gave us ample time to access everything we needed.
What We Accessed:
Using Mark's credentials, we accessed:
- Email inbox -- full access to sent, received and archived communications
- SharePoint and OneDrive -- including a file titled "Browser Passwords.csv" stored in his personal OneDrive
We downloaded the password file. While it primarily contained credentials for personal accounts (outside the engagement scope), the passwords revealed common patterns the user employed -- information that could be used for password spraying and credential stuffing in subsequent attack phases.
- Internal compliance folders -- including regulatory and audit documentation
- Internal business applications -- we discovered that Organisation Alpha's internal portal was integrated with O365 SSO, meaning we could access it without entering additional credentials
The SSO integration gave us access to the full internal application suite, logged in as Mark Davidson -- including the staff phonebook, internal tools and departmental resources.
Case 3: "Mei Lin" -- Full Compromise + Lateral Phishing from Compromised Account
Date: Week 5 of engagement
This case was particularly significant because it demonstrated how a single compromised account can be weaponised for lateral movement -- and exposed a systemic organisational vulnerability.
Initial Compromise:
Using the same IT support pretext, the RT member called Mei Lin. During the conversation, she mentioned she was already experiencing issues accessing a shared network drive -- giving us a natural opening. She also confirmed that she had not yet been enrolled in 2FA for her O365 account.
Sensing the opportunity, we pivoted our pretext: rather than the migration story, we told her we needed to set up her 2FA to resolve the drive access issues. We sent her an email with "2FA setup instructions" containing our credential harvesting link. The email landed in her junk folder, but we convinced her to retrieve it, mark the sender as safe and follow the link.
She submitted her credentials on our cloned portal. Since no 2FA was configured, we specifically chose SMS-based verification during our setup (rather than the Microsoft Authenticator app) because text-based codes have an extended validity period -- giving us more time to use them.
After she submitted her credentials on the harvesting page, she was automatically redirected to a fake verification code page. We convinced her to enter the SMS code she received as "part of the setup process." With credentials and the 2FA code in hand, we gained full access.
We selected "Don't ask again for 30 days" to maintain persistent access.
What Made This Case Unique -- Three Critical Discoveries:
Discovery 1: Plaintext Passwords in Email While enumerating Mei Lin's inbox, we found a password reset confirmation email from an internal business application -- Organisation Alpha's Resource Centre portal -- containing the account password in plaintext in the email body. We used these credentials to successfully access the Resource Centre application.
Discovery 2: The Chrome Password Export Guide While navigating Mei Lin's SharePoint, we found a document titled "Export Browser Passwords" -- an instruction guide created by the IT team explaining how to export saved browser passwords and store the file locally.
In Case 2 (Mark Davidson), we had already discovered a browser password CSV on his OneDrive and assumed it was an isolated case. This documented guide revealed it was actually organisational practice -- meaning that if a significant number of accounts were compromised, an adversary could potentially harvest browser passwords from every staff member's OneDrive. This represented a systemic credential exposure risk.
Discovery 3: Weaponising the Compromised Account for Lateral Phishing
With full access to Mei Lin's legitimate email account, we decided to use it to send phishing emails to other staff members. Emails sent from a real internal account would bypass EOP filtering entirely -- no domain reputation issues, no SPF/DKIM failures, no junk folder.
We crafted a seasonal pretext: a holiday gift notification email, sent from Mei Lin's account to selected targets, informing them they had been chosen to receive a special end-of-year gift and needed to log in to claim it. The login page was, of course, our cloned credential harvesting portal.
One recipient ("Ed") replied to the email saying the link wasn't working. This reply went directly to Mei Lin's inbox -- creating a risk that she would notice the phishing emails being sent from her account.
Counter-Detection Measures:
To prevent Mei Lin from discovering the phishing campaign running through her account, we created an Outlook mail rule that automatically deleted any reply emails from the gift notification recipients. This meant:
- Mei Lin would never see responses from confused or suspicious recipients
- The phishing campaign could continue undetected from her account
- Only if a recipient contacted Mei Lin through a different channel (phone, in person) would the activity be exposed
Note: During the engagement, access to the account was lost before the RT members could remove this email rule. The IT team was advised to check for and remove any rogue mail rules on the account.
Case 4: "Rachel Torres" -- Partial Compromise (Target Became Suspicious)
Date: Week 5 of engagement
This case is noteworthy because it demonstrates that security awareness training does work -- even if it doesn't always prevent the initial credential capture.
The Approach:
Same pretext as previous cases. The RT member called Rachel posing as IT support and convinced her to enter her credentials on the cloned portal. She complied.
The Turning Point:
When we asked her for the 2FA verification PIN that had been sent to her phone, she paused. Unlike previous targets who provided the code without hesitation, Rachel requested to put us on hold while she confirmed the process with a colleague.
The RT member immediately recognised that continuing would risk exposure of the broader campaign. We concluded the call before she returned.
What This Tells Us:
Her credentials were valid -- we were able to confirm this because the O365 2FA prompt appeared, which only triggers after successful username/password authentication. However, her instinct to verify with a colleague before providing the 2FA code prevented full account compromise.
This is a textbook example of the "trust but verify" behaviour that security awareness training aims to instil. While the social engineering was convincing enough to get her to submit her password, the additional step of 2FA verification gave her a natural pause point to question the interaction.
Case 5: "Marcus Wei" -- Credential Compromise (Blue Team Adaptation Detected)
Date: Week 5 of engagement
This case revealed that Organisation Alpha's security team was actively responding to the engagement in real-time.
The Approach:
The RT member called Marcus posing as IT support. During the call, Marcus mentioned a couple of genuine IT issues he'd been experiencing, which gave the pretext additional credibility. He agreed to a callback later that day.
In the follow-up call, we provided the phishing URL verbally over the phone and convinced him to visit it. He submitted his credentials.
The Unexpected Roadblock:
When we attempted to log in using Marcus's credentials, we received an error message: "You cannot access this right now." The error confirmed that the username and password were correct (the authentication step succeeded), but login was blocked because the device did not meet the compliance criteria.
This was new. Earlier compromised accounts had not encountered this restriction.
Our Conclusion:
Organisation Alpha's blue team had most likely detected the earlier compromised account logins from untrusted devices and updated the M365 Conditional Access policies to restrict authentication to trusted/managed devices only.
This was a significant defensive adaptation. Our typical counter-strategy in such scenarios would be to arrange an in-person meeting with the target and use their corporate device to log in. However, given the time constraints and scope boundaries, we documented the credential compromise and moved to the next target.
The same device restriction was encountered on several subsequent compromises -- confirming that the blue team had rolled out the policy change organisation-wide in response to our activities.
Case 6: "Priya Sharma" -- Credential Compromise via MS Teams Chat
Date: Week 6 of engagement
This case demonstrated another approach to bypassing email-based detection -- using real-time collaboration tools.
The Approach:
Similar to Case 1, the RT member posed as IT support and convinced Priya to join an MS Teams session to resolve her reported issues. The decision to use Teams (rather than a call + email) was deliberate: we wanted to share the phishing URL via the Teams chat window rather than email, avoiding O365 email filtering entirely.
During the Teams session, we shared the credential harvesting URL via chat. Priya visited the URL and submitted her credentials.
The Outcome:
Like Case 5, when we attempted to use her credentials, the device compliance policy blocked access from our non-corporate system. The authentication was successful (confirming valid credentials), but the conditional access policy prevented account access.
This further confirmed that the blue team's device restriction policy was now consistently applied across the organisation.
Accounts Compromised: Summary
Through a combination of social engineering, phishing and hybrid approaches, the following accounts were compromised during this phase:
| # | Alias | Compromise Method | Approach | Full Access Achieved? |
|---|---|---|---|---|
| 1 | Sarah Chen | Credentials submitted via cloned portal | SE + Phishing | ✅ Yes (incl. 2FA bypass) |
| 2 | Mark Davidson | Password reset via SE manipulation | SE Only | ✅ Yes |
| 3 | Linda Torres | Password reset via SE manipulation | SE Only | ✅ Yes |
| 4 | Mei Lin | Credentials submitted + 2FA bypass | SE + Phishing | ✅ Yes (used for lateral phishing) |
| 5 | Rachel Torres | Credentials submitted (2FA blocked) | SE + Phishing | ⚠️ Partial (target became suspicious) |
| 6 | Marcus Wei | Credentials submitted (device policy blocked) | SE + Phishing | ❌ Creds valid, device policy blocked |
| 7 | Priya Sharma | Credentials submitted via Teams chat | SE + Phishing | ❌ Creds valid, device policy blocked |
| 8 | Donna Mitchell | Credentials submitted via cloned portal | Phishing Only | ❌ Creds valid, device policy blocked |
| 9 | James Elliot | Credentials submitted + device details captured | Phishing Only | ❌ Creds valid, device policy blocked |
| 10 | Karan Mehta | Credentials submitted via cloned portal | SE + Phishing | ✅ Yes |
Key Observations
The Blue Team Fought Back
One of the most interesting aspects of this engagement was witnessing Organisation Alpha's security team adapt in real-time. After detecting logins from untrusted devices on the early compromised accounts, they rolled out a Conditional Access policy restricting authentication to managed corporate devices only. This effectively neutralised our remote access capability for all subsequent account compromises.
This is exactly the kind of active defence posture that turns a red team engagement from a one-sided exercise into a genuine adversarial simulation.
Why the Combined Approach Was Devastating
The hybrid social engineering + phishing approach was far more effective than either technique alone:
- Phone calls established trust before the phishing email arrived -- targets were expecting the email and actively looking for it
- Real-time adaptation allowed us to overcome obstacles (emails in junk, 2FA prompts) that would have killed a standard phishing campaign
- Internal knowledge (helpdesk names, migration details, system names) made every interaction feel legitimate
- Video chat and Teams sessions provided both a surveillance channel and a way to deliver phishing URLs that bypassed email filtering entirely
Lateral Phishing: The Force Multiplier
The Mei Lin case demonstrated the devastating potential of lateral phishing. Once we had access to a legitimate internal email account, we could send phishing emails that would:
- Bypass all email filtering (sent from a trusted internal address)
- Appear in the inbox (not junk) with correct sender reputation
- Include legitimate email signatures and formatting
- Be backed by social proof (recipients knew the sender)
Combined with the Outlook rule to suppress replies, this created a near-undetectable phishing capability from within the organisation.
The Chrome Password Export: A Systemic Risk
The discovery of an IT-documented guide for exporting browser passwords to local storage meant that a mass account compromise could cascade into a complete credential exposure event -- not just for Organisation Alpha's systems, but for any personal or third-party service where staff had saved passwords in their browser.
What Traditional Phishing Would Have Missed
A standard phishing campaign against Organisation Alpha would likely have achieved a near-zero success rate. EOP was filtering effectively, staff were trained to report suspicious emails and the security team was monitoring for phishing indicators.
Our success came from treating phishing as one component of a larger social engineering operation -- not as a standalone attack vector.
What Comes Next
In Part 3, we will cover:
- Lateral movement through internal systems using compromised credentials
- Privilege escalation via intelligence gathered from email archives and shared drives
- Physical security assessment -- using digital access to enable physical breach
- Final flag capture and engagement conclusion
Written by Debasis Mohanty (nopsled) -- Based on a real-world engagement. All names, email addresses and identifying details have been fabricated. The industry and business domain have been intentionally obscured to honour client confidentiality and contractual obligations.