Red Teaming Story — Part 2: Technical Impact, Detection and Lessons for Defenders

Part 2 of a real-world red-team story examining how a trusted email workflow could be transformed into a wider initial-access and business-compromise scenario.

Recap of Part 1

In Part 1, we examined how a public-facing contact form contained an unsafe trust model.

A sender-related value could be influenced by an external user, allowing an email generated through the organization’s own application and mail-delivery path to appear as though it originated from a legitimate internal identity.

The weakness was more significant than ordinary email spoofing because the message was generated through trusted infrastructure. This increased its credibility and could potentially reduce the effectiveness of controls designed primarily to inspect hostile external mail.

The attack path developed as follows:

Part 2 examines what this attack path could enable, why expensive security technologies did not automatically eliminate the risk, and how organizations can detect and remediate similar conditions.

---

Potential Technical Impact

If abused by a real attacker, the misconfiguration could support several attack outcomes.

Credential Theft

A trusted-looking message could direct a recipient to a fraudulent authentication page designed to capture credentials.

Credentials may then provide access to:

• Webmail
• VPN services
• Cloud applications
• Collaboration platforms
• Source-code repositories
• Customer portals
• Internal dashboards
• Remote-access systems

The exact impact would depend on the privileges of the affected account, the presence of MFA, conditional-access policies, device requirements, and the organization’s ability to detect unusual authentication activity.

A single compromised account may also expose information that helps the attacker target more privileged users.

Session or Token Theft

Modern attacks do not always stop at usernames and passwords.

Where authentication tokens or browser sessions are targeted, an attacker may attempt to reuse an authenticated session rather than perform a conventional login.

This matters because some identity protections are designed primarily to stop password-based attacks. Organizations should therefore evaluate:

• Token lifetime
• Session binding
• Device compliance
• Reauthentication requirements
• Conditional-access enforcement
• Risk-based session revocation
• Authentication context
• Browser and endpoint telemetry

Phishing-resistant MFA and device-bound authentication can significantly reduce this class of risk.

Malware Delivery

A trusted sender identity may increase the likelihood that a recipient opens a document, archive, shortcut, or link leading to payload delivery.

The delivery method itself is only one stage of the attack chain. Further success may depend on:

• Endpoint protection
• Application-control policies
• Macro restrictions
• Browser protections
• File reputation
• User privileges
• Network egress controls
• Command-and-control detection
• Security monitoring

During a red-team exercise, any payload should be designed according to the rules of engagement, include safety controls, and avoid unnecessary impact on production systems.

Business Email Compromise

The same impersonation weakness could potentially support fraudulent business requests without requiring malware.

Examples include:

• Payment redirection
• Invoice manipulation
• Payroll-account changes
• Procurement fraud
• Requests for confidential documents
• Requests to bypass normal approval procedures
• Requests for passwords or MFA approval
• Urgent instructions appearing to come from senior leadership

These scenarios can be highly effective because they target business processes rather than technical vulnerabilities.

A technically secure endpoint may still be used to perform an unauthorized bank transfer if the employee believes the request is legitimate.

Internal Reconnaissance

Even when a recipient does not provide credentials or execute a file, a reply can disclose useful information.

This may include:

• Internal signatures
• Telephone numbers
• Reporting structures
• Project names
• Technology details
• Employee availability
• Internal vocabulary
• Supplier relationships
• Email formatting conventions
• Escalation and approval processes

This information can make later social-engineering attempts more convincing.

Password-Reset Abuse

A message appearing to originate from IT support or the security team may persuade a user to follow a fraudulent password-reset workflow.

The attacker may imitate:

• Account-expiration warnings
• Security-verification requests
• Mailbox-quota notifications
• MFA-registration requests
• Device-enrolment instructions
• VPN password resets
• Suspicious-login alerts

This type of attack exploits the expectation that security teams sometimes contact users about urgent account issues.

Reputation Damage

If the organization’s own web infrastructure is abused to generate deceptive messages, customers, partners, and employees may lose confidence in its communications.

The organization may then face questions such as:

• Can legitimate email from the domain still be trusted?
• Were customer messages exposed?
• Was an internal account compromised?
• Was the mail server breached?
• How long was the functionality exposed?
• Were external parties targeted?

Even after remediation, restoring trust may require customer communication, monitoring, and incident-response activity.

Detection and Response Burden

The incident may initially appear to be legitimate application traffic.

Security teams may need to determine whether the message was:

• Externally spoofed
• Sent by a compromised employee account
• Generated by an internal application
• Sent through an approved third-party service
• Produced through a vulnerable contact form
• Part of a larger identity compromise

Without sufficient logging, correlating the original web request with the generated email may be difficult.

---

Why Existing Security Technology Did Not Eliminate the Risk

The organization had security technology. The problem was not the total absence of controls.

The problem was that trust had been granted to a workflow that was not securely implemented.

Endpoint Protection Has a Different Role

Endpoint protection is designed to detect suspicious processes, files, behaviors, and network activity on managed devices.

It cannot prevent every user from:

• Entering credentials into a fraudulent webpage
• Approving an unexpected MFA request
• Responding to a fraudulent business request
• Sharing information with an apparently trusted sender
• Following an unsafe process from an unmanaged device

Endpoint security remains essential, but it cannot compensate for every failure in identity, email, application design, or business verification.

Email Security May Trust Approved Infrastructure

A secure email gateway may make different decisions when a message originates from:

• An approved SMTP relay
• A trusted application
• A recognized SaaS platform
• An internal email path
• Infrastructure authorized to send for the organization’s domain

If that trusted system accepts attacker-controlled identity data, the attacker may inherit some of the system’s reputation.

Vulnerability Scanners May Miss Business Context

A scanner might identify weak input validation, header manipulation, or an insecure mail function.

However, it may not determine that:

• The message appears internal
• External-email warnings are absent
• The identity of a senior executive can be impersonated
• The mail path is trusted by the secure email gateway
• The issue could support credential theft or financial fraud
• The weakness can be chained with public employee information

Understanding this impact requires context.

SIEM Platforms Require Relevant Detection Logic

A SIEM cannot alert effectively on a condition that has not been defined, logged, or correlated.

Detection may fail when:

• The application does not log sender values
• The SMTP relay does not record the originating application
• Web and email logs use unrelated identifiers
• No alert exists for unexpected sender identities
• Automated mail is treated as low risk
• Security teams do not monitor public-form abuse
• Relevant telemetry is retained for too short a period

MFA Is Important but Not Universal Protection

MFA significantly reduces the risk of password-only compromise.

However, the wider attack may still involve:

• Social engineering for MFA approval
• Session or token theft
• Adversary-in-the-middle techniques
• Help-desk manipulation
• Business email compromise
• Sensitive-information requests
• Attacks against services without strong MFA
• Legacy authentication paths

The strongest protection comes from phishing-resistant authentication, device-aware access controls, robust session management, and user-verification procedures.

An expensive security product deployed around an unsafe process does not make the process safe.

---

Root Cause Analysis

The primary technical weakness was insufficient control over the sender identity used by the public web application.

The broader root cause involved several security-design failures.

Untrusted Input Influenced a Trusted Identity

A public user was able to affect information that should have been controlled exclusively by the application.

Security-sensitive fields should not inherit their values directly from unauthenticated client input.

Trust Was Assigned Based on Infrastructure

The resulting message inherited trust because it was processed through an approved application or email path.

The infrastructure was trusted, but the data entering that infrastructure was not adequately constrained.

Sender Authorization Was Not Enforced at the Application Boundary

The application should have been allowed to send only from a small, predefined set of addresses.

The SMTP relay should also have enforced those restrictions rather than assuming the application would always behave securely.

Business Functionality Was Not Treated as an Attack Surface

The contact form may have been considered low risk because it did not provide authentication, file upload, or direct access to sensitive information.

However, it had the ability to trigger a trusted action: sending email.

Any feature that causes another system to perform an action should be evaluated as a trust boundary.

Security Controls Were Evaluated Individually

The web application, SMTP relay, email-security controls, identity platform, and user-awareness process may each have been reviewed separately.

The risk emerged from how they interacted.

This demonstrates why architecture reviews and attack-path analysis are necessary in addition to component-level testing.

---

Detection Opportunities

Organizations should monitor application-generated email as carefully as user-generated email.

Unexpected Sender Identities

Alert when a public application attempts to send email using an address outside its approved sender list.

For example, a contact-form application should never generate messages appearing to originate from:

ceo@example.com
finance@example.com
security@example.com
administrator@example.com

unless there is a documented and securely implemented business requirement.

Executive or Privileged Identity Use

Detect when a contact form, marketing platform, ticketing system, or other automated service generates a message claiming to originate from:

• Executives
• Finance personnel
• IT administrators
• Security personnel
• Shared privileged mailboxes
• Legal or compliance teams
• Human-resources personnel

These identities carry increased social-engineering value.

Header Inconsistencies

Review discrepancies between:

• Envelope sender
• Visible From
• Reply-To
• Return path
• Authenticated sending service
• Application identifier
• DKIM signing domain
• SPF evaluation domain

A message may be technically authenticated while still presenting an unauthorized identity if an approved application is misused.

Unusual Contact-Form Activity

Monitor for:

• Repeated submissions
• High-volume activity
• Changes in sender domains
• Encoded or obfuscated content
• Suspicious URLs
• Requests targeting many internal recipients
• Attempts to use organizational email addresses as sender values
• Multiple submissions with different executive identities
• Activity from unusual geographic locations
• Automated submission patterns

Mail-Flow Anomalies

Correlate web application logs with SMTP and email-gateway logs.

A security team should be able to trace:

HTTP submission
→ application event
→ SMTP transaction
→ delivered message
→ recipient interaction

Correlation becomes easier when each event includes a shared transaction or message identifier.

Identity and Endpoint Signals

Where a user interacts with the message, defenders should correlate:

• Link-click telemetry
• DNS requests
• Proxy logs
• Browser activity
• Authentication events
• MFA prompts
• Session creation
• Endpoint processes
• Network connections
• Cloud audit logs

User Reporting

Provide a simple mechanism for users to report suspicious messages, including messages that appear to come from internal senders.

A message should not be considered safe merely because it appears internal.


---

Mitigation Recommendations

1. Use a Fixed Sender Address

Public forms should send messages from a predefined account such as:

website-contact@example.com

Visitors should never control the visible From address.

2. Place the User Address in Reply-To

Where business functionality requires replying to the submitter, their validated address should be placed in the Reply-To field rather than the sender field.

3. Restrict SMTP Relay Permissions

The mail relay should permit each application to use only explicitly authorized sender addresses.

The relay should reject attempts to send as executive, administrative, finance, security, or arbitrary user accounts.

4. Validate All Header-Related Input

Reject:

• Unexpected control characters
• Line breaks
• Malformed addresses
• Unauthorized domains
• Multiple addresses where only one is expected
• Values outside the documented business requirement

5. Separate Application Mail From User Mail

Use a dedicated subdomain or clearly identifiable sender namespace for automated messages, for example:

notifications.example.com

This makes policy enforcement and monitoring easier.

6. Label Automated and Externally Triggered Messages

Messages generated by public users should contain clear indicators that they originated through an external-facing form.

The label should be difficult for the submitter to remove or modify.

7. Review SPF, DKIM and DMARC Architecture

These controls are important, but they must be evaluated together with:

• Internal relays
• SaaS senders
• Web applications
• Marketing platforms
• Ticketing systems
• Trusted mail routes
• Subdomains
• Third-party providers

Domain authentication alone may not prevent misuse by an already-authorized sender system.

8. Apply Rate Limiting and Abuse Controls

Implement:

• Rate limits
• CAPTCHA where appropriate
• Bot detection
• Submission throttling
• Destination restrictions
• Content inspection
• Abuse monitoring
• Automated blocking
• Alerting on repeated impersonation attempts

9. Test Business Workflows During Security Assessments

Do not limit assessments to common vulnerability classes.

Test how public functionality interacts with:

• Email
• Identity
• Customer records
• Document generation
• Notification services
• Support systems
• Internal approval workflows

10. Strengthen Identity Controls

Use:

• Phishing-resistant MFA
• Conditional-access policies
• Device-compliance requirements
• Session monitoring
• Risk-based authentication
• Rapid token revocation
• Legacy-authentication restrictions
• Strong help-desk verification procedures

11. Train Users to Verify Context, Not Only Sender Addresses

Employees should verify unusual requests through an independent channel, especially requests involving:

• Credentials
• Payments
• Sensitive documents
• MFA approvals
• Software installation
• Changes to account information
• Urgent requests from executives
• Bypassing established procedures

---

Broader Lesson: Security Is an Outcome, Not a Product

Security technology remains essential.

Organizations should deploy modern endpoint protection, email security, identity controls, network monitoring, vulnerability management, and incident-response capabilities. They should keep those technologies updated and correctly maintained.

However, acquiring advanced technology is not the same as achieving security.

A product may be:

• Incorrectly configured
• Partially deployed
• Missing relevant telemetry
• Applied to only part of the environment
• Trusted too broadly
• Disconnected from business processes
• Unable to understand organizational context
• Unable to detect abuse of legitimate functionality

This engagement demonstrated that a comparatively simple misconfiguration could create a path around several expensive controls.

The finding did not mean the organization’s security investments were useless. Those controls would still play important roles in preventing escalation, detecting suspicious behavior, limiting access, and supporting incident response.

The lesson was that no single control could compensate for an unexamined trust relationship.

---

Key Takeaways

Technology Is Necessary, but Not Self-Sufficient

Security tools require correct architecture, implementation, integration, monitoring, and continuous validation.

Simple Misconfigurations Can Create Serious Attack Paths

An issue does not need a high CVSS score or sophisticated exploit to produce significant business impact.

Trusted Infrastructure Can Be Abused

Defenders must assess not only hostile external systems, but also legitimate systems that may be manipulated into performing attacker-controlled actions.

Human-Led Testing Connects Technical and Business Risk

The value of red teaming lies in understanding how people, processes, identities, and technologies interact.

The Human Element Is Both a Risk and a Defence

Employees may be targeted through social engineering, but trained and supported employees can also become one of the organization’s strongest detection layers.

Red Teaming Should Evaluate the Full Attack Chain

A mature engagement should test prevention, detection, response, containment, and organizational decision-making—not merely whether a vulnerability exists.

---

What Comes Next

Parts 1 and 2 covered the discovery of a trusted email-impersonation path, its potential impact, and the defensive lessons arising from it.

The next chapter will examine the controlled development and use of a reverse-connection capability during the engagement.

That discussion will focus on:

• The operational objective
• Payload-design considerations
• Command-and-control architecture
• Evasion versus safety constraints
• Endpoint-security interaction
• Detection opportunities
• Lessons for defenders

Sensitive implementation details, customer information, and reusable offensive components will remain sanitized.


---

Final Thought

The most important outcome of this engagement was not that a contact form was misconfigured.

It was that an apparently minor weakness could be transformed into a credible route toward initial access because several systems and people trusted the identity presented by that workflow.

Modern security requires advanced technology. But technology must be implemented with the assumption that every trusted process may eventually be tested by an intelligent and adaptive adversary.

That is why human-led offensive security remains essential.

Automated tools identify weaknesses.

Experienced red-team operators determine what those weaknesses can become.

---

Responsible Disclosure and Confidentiality Notice

This article describes an authorized security assessment. Organization names, domains, addresses, infrastructure details, payload information, and other identifying data have been removed or altered.

The purpose of this article is to share defensive lessons and demonstrate the value of human-led security testing. It should not be interpreted as authorization to test systems without explicit written permission.

Author: Moe Khalilov
Founder, LeetProtect