Red Teaming Story — Part 1

Executive Summary

Organizations invest heavily in endpoint detection and response, secure email gateways, firewalls, vulnerability scanners, identity protection, and security monitoring. These technologies are essential, but their presence does not automatically make an organization secure.

Security products only protect the systems, identities, and communication paths they can correctly observe and control. A single overlooked application function, weak trust assumption, or configuration error can create an alternative route around multiple defensive layers.

During an authorized red-team engagement, our objective was to identify a realistic path to initial access without relying exclusively on conventional vulnerability scanning or noisy exploitation techniques.

While reviewing the target’s external attack surface, we discovered that a public-facing contact form could be manipulated to generate email messages that appeared to originate from legitimate addresses belonging to the organization. This created a trusted communication path that could potentially be abused for internal impersonation and social engineering.

The issue was technically simple. Its potential consequences were not.

The engagement demonstrated an important red-team principle:

Attackers do not need to defeat every security control. They only need to identify one trusted workflow that the organization has not adequately secured.

---

Why the Human Element Still Matters

Automated vulnerability scanners are valuable for identifying exposed services, missing patches, known vulnerabilities, weak configurations, and other repeatable technical conditions.

However, a scanner normally evaluates individual assets or predefined security checks. A red-team operator evaluates relationships between systems, people, business processes, identities, and trust boundaries.

That distinction is critical.

An automated tool might examine:

• Whether a web application contains known vulnerabilities
• Whether a server is missing security patches
• Whether a TLS configuration is weak
• Whether an exposed service matches a known signature
• Whether a software component contains vulnerable code

A human-led red-team exercise asks broader questions:

• Can a public business process be transformed into an internal attack path?
• Does the organization trust messages because they appear to come from its own domain?
• Can one weak application workflow undermine stronger email controls?
• Will employees respond differently when a message appears to originate from a senior executive?
• Can several individually minor weaknesses be combined into a meaningful compromise?
• Can an attacker use legitimate infrastructure to avoid looking like an external threat?

This is why the human element should not be understood only as the employee who clicks a malicious link.

The human element exists throughout the security lifecycle:

• A developer decides how user-supplied email fields are processed.
• An administrator configures the mail relay.
• A security architect defines which systems are trusted.
• A monitoring team decides which events should generate alerts.
• An employee determines whether a message appears credible.
• A manager approves an urgent request based on the apparent sender.
• A security tester decides whether several small observations can form a viable attack chain.

Industry breach reports consistently show that social engineering, credential abuse, and human error remain central components of real-world compromises. This does not mean employees are inherently the problem. It demonstrates that attackers repeatedly target human trust, identity, and organizational processes because those areas remain effective points of entry.

---

What Red Teaming Is Really Designed to Test

A penetration test commonly focuses on finding and validating vulnerabilities within a defined technical scope.

A red-team engagement generally goes further. It evaluates whether an attacker can achieve an agreed objective by combining weaknesses across the organization’s complete attack surface.

Depending on the authorized scope, this may include:

• External infrastructure
• Web applications
• Cloud services
• Identity systems
• Email infrastructure
• Remote-access services
• Third-party platforms
• Exposed documents and metadata
• Employee information
• Business workflows
• Physical or wireless controls
• Security monitoring and response
• Trust relationships between systems

The purpose is not merely to produce a long list of findings. It is to determine whether weaknesses can be chained together to create operational impact.

A vulnerability scanner might identify ten medium-risk issues. A skilled operator may discover that three apparently low-risk observations can be combined to impersonate an internal user, capture valid credentials, and establish an initial foothold.

That attack chain is often far more important than the individual severity assigned to each component.

---

Engagement Context

The organization involved in this engagement had invested in multiple defensive technologies.

Its environment included controls intended to protect endpoints, email communications, identities, and network access. From a conventional security perspective, directly delivering an external phishing message or malicious attachment would be expected to encounter several layers of protection.

Our first challenge was therefore not simply:

“Can we send a phishing email?”

The more useful question was:

“Can we identify a legitimate organizational workflow that allows a message to inherit trust before it reaches the recipient?”

This changed the direction of our reconnaissance.

Rather than immediately attempting to bypass the organization’s email-security stack, we reviewed its external applications and communication mechanisms to identify systems that were already authorized to send email on behalf of the organization.

That approach eventually led us to a public contact form.

---

Phase One: External Attack-Surface Reconnaissance

The initial phase of a red-team engagement is often associated with domain enumeration, port scanning, service fingerprinting, subdomain discovery, credential-leak searches, and vulnerability identification.

Those activities are important, but attack-surface analysis must also include business functionality.

Public websites frequently contain features such as:

• Contact forms
• Support-ticket portals
• Newsletter subscriptions
• Password-reset workflows
• Recruitment platforms
• Customer-notification systems
• Document-sharing functions
• Appointment-booking systems
• Automated reporting features
• Email invitation mechanisms

These features are valuable to attackers because they cross security boundaries. A user submits data through a web application, and the application causes another trusted system—often an internal mail server or third-party provider—to take an action.

Our review therefore focused not only on whether the contact form was technically vulnerable, but also on how it handled trust.

We examined questions such as:

• Which fields were controlled by the user?
• Which fields were inserted into the generated email?
• Which server delivered the message?
• Did the application distinguish between display names, reply addresses, envelope senders, and visible sender headers?
• Was the sender identity defined by the server or accepted from user input?
• Did the resulting email pass through an infrastructure path trusted by the organization?
• Would the recipient see external-message warnings?
• Would the message appear to come from inside the organization?

---

Discovery: A Contact Form With an Unsafe Trust Model

The contact page allowed visitors to submit information that would be delivered to a designated recipient.

At first glance, this appeared to be ordinary website functionality.

During controlled testing, however, we observed that a sender-related value could be influenced by the requester. Instead of safely using the submitted address only as a reply destination or message-body value, the application incorporated it into the generated email’s apparent sender identity.

For example, a normal contact-form submission might be expected to produce a message resembling:

From: contact-form@example.com
Reply-To: visitor@example.net
To: internal-recipient@example.com

In a safer implementation:

• The From address is fixed and controlled by the application.
• The visitor’s email address is placed in Reply-To.
• The application does not permit arbitrary control over the sender identity.
• The email can be clearly identified as originating from a public form.

In the vulnerable workflow, the sender-related value was not adequately constrained. As a result, the generated message could appear to originate from another address associated with the organization.

The exact implementation may vary between applications. Common causes include:

• Trusting a client-controlled sender field
• Building email headers directly from form parameters
• Failing to validate the permitted sender domain
• Confusing the From and Reply-To fields
• Allowing an application relay to submit arbitrary sender identities
• Applying authentication policies at the domain level while overlooking trusted application-originated mail
• Treating messages from an internal relay as inherently trustworthy

This was not necessarily a sophisticated software vulnerability. It was a failure in how trust was implemented across the web application and mail-delivery process. Contact form was simple and straight forward to modify and impersonate the sender. We tested with our own email to start with.

---

How the Email Impersonation Worked

Email contains several identity-related fields, and they do not all serve the same purpose.

At a high level, a message may include:

• Envelope sender: Used during SMTP transport and for handling delivery failures.
• Visible From header: The identity normally displayed to the recipient.
• Reply-To header: The address used when the recipient replies.
• Display name: The human-readable name shown by the mail client.
• Authenticated sending system: The server or service that actually submitted the message.

Security controls may inspect some or all of these values. However, problems arise when a trusted application is allowed to generate messages while accepting identity information from an untrusted user.

In our case, the message did not arrive through an obvious attacker-controlled email server. It was generated through the target’s own web application and mail-delivery path.

This mattered because defensive controls often evaluate context:

• Where did the message originate?
• Was it delivered through an approved relay?
• Did it come from a known application?
• Was the sending infrastructure already trusted?
• Did the message appear internal?
• Were external-sender banners applied?
• Did the domain authentication outcome match the sending architecture?

The contact form effectively acted as a bridge between an unauthenticated internet user and a trusted mail-sending workflow.

The vulnerability was therefore not simply “email spoofing.” It was the ability to misuse a legitimate organizational function to generate a message carrying an unauthorized identity.

---

Controlled Validation

Before proceeding further, we validated the behavior against an authorized test mailbox.

We substituted the sender identity with a controlled example representing an internal organizational role. When the message arrived, the recipient-facing interface displayed the selected organizational address rather than a clearly identifiable contact-form sender.

This confirmed several important points:

1. The sender identity could be influenced.
2. The message was delivered successfully.
3. The visible sender appeared associated with the target organization.
4. The delivery path did not present the message as an ordinary external email.
5. The technique could increase the credibility of a social-engineering pretext.

Testing first against a controlled mailbox was essential. Red-team validation should demonstrate the issue while minimizing unnecessary exposure and operational risk.

For confidentiality reason, we can’t share the actual email but anytime you receive an email, it is a good habit to check key indicators of malicious email. see below with sample checks.

---

Why This Was More Serious Than Ordinary Spoofing

Traditional spoofed email often originates from attacker-controlled infrastructure. Secure email gateways may detect it through sender-authentication failures, domain reputation, known malicious infrastructure, suspicious content, or inconsistencies between the sender and the sending system.

This case was different.

The attacker-controlled input was processed by infrastructure already associated with the organization. That could provide several advantages from an attacker’s perspective.

1. Increased Sender Credibility

Recipients are more likely to trust a message that appears to originate from:

• A senior executive
• Human resources
• Finance
• IT support
• Security operations
• A project manager
• A colleague involved in an active business process

The visible identity changes how a recipient evaluates urgency, legitimacy, and risk.

2. Reduced Effectiveness of Perimeter-Based Controls

A security stack designed to inspect hostile external mail may make different trust decisions when a message originates from a known web application or approved relay.

3. Absence of External-Email Warnings

Many organizations display banners such as:

Warning: This message originated outside the organization.

If the message is classified as internally generated or trusted, that visual warning may not appear.

4. Abuse of Legitimate Infrastructure

The activity may blend with normal contact-form traffic and application-generated mail. This can make initial detection more difficult unless the organization monitors sender anomalies and application-mail behavior.

5. Bypass of User Expectations

Security-awareness training often teaches users to examine the sender’s domain. That advice becomes less effective when the message appears to use the organization’s genuine domain and trusted delivery workflow.

6. Executive Impersonation Risk

An attacker does not always need malware. A credible message appearing to come from a senior person could be used to request:

• Credential verification
• Payment changes
• Sensitive documents
• Password resets
• MFA approvals
• Internal information
• Access to a shared resource
• Urgent action outside normal procedure

The business risk therefore extends beyond technical compromise.

---

From Misconfiguration to a Potential Initial-Access Path

Once the impersonation behavior had been validated, the next step was to evaluate whether it could support a realistic initial-access scenario.

Within the authorized rules of engagement, a message could be designed to appear as though it came from a trusted internal identity. Depending on the agreed test objectives, it could contain a controlled link, benign simulation document, or credential-awareness exercise.

The potential attack chain was:

This illustrates an important red-team concept: the original weakness was not the final objective.

The contact-form flaw was an enabler. Its value came from how it could be combined with identity, trust, and user behavior.

The Role of Social Engineering

Social engineering is sometimes described too narrowly as “tricking a user.”

In practice, effective social engineering exploits context.

A credible scenario may be based on:

• Organizational hierarchy
• Current projects
• Publicly announced events
• Job responsibilities
• Reporting relationships
• Business urgency
• Existing communication styles
• Known suppliers or partners
• Internal naming conventions
• Common document-sharing workflows

The technical issue gave us the ability to influence the apparent sender. Human-led reconnaissance would determine which identity, timing, wording, and business context would make the communication believable.

This is another area where automated tools have limitations.

A scanner can report that a sender field is insufficiently validated. It cannot fully measure:

• Which organizational role creates the strongest trust response
• Whether the recipient is expecting a related communication
• How an internal workflow could support the pretext
• Whether the message would bypass established verification habits
• Which sequence of actions would most realistically achieve the engagement objective

That requires judgment, contextual awareness, and an understanding of human behavior.

The lesson is not that users are careless. The lesson is that attackers create scenarios specifically designed to trigger quick decisions under conditions of familiarity, authority, urgency, or fear.

---

Conclusion: A Misconfiguration Is Only the Beginning

At this point in the engagement, we had not simply identified a weak contact form.

We had discovered a trusted communication path that could potentially be transformed into an initial-access mechanism.

The finding demonstrated how a public-facing application, an email relay, organizational identity, and human trust could be combined into a single attack chain. Each component might appear manageable when reviewed separately. Together, they created a much more serious risk.

This is precisely where human-led red teaming provides value.

The operator does not stop after identifying the technical weakness. The operator asks:

• What does this weakness allow us to become?
• Which security boundary can it help us cross?
• Which controls might it bypass?
• How would a real attacker integrate it into a wider operation?
• What would the organization detect, and what might remain invisible?

In Part 2, we will continue from this point and examine the potential technical and business impact of the attack path, why existing security technologies did not fully eliminate the risk, and how organizations can detect and remediate similar weaknesses.

---

Author: Moe Khalilov
Founder, LeetProtect