M09-01 · Social engineering and human trust

Social Engineering & Human Trust

Module 09: Social Engineering

In this lesson, we will not only understand how attackers exploit interpersonal trust, but also connect the CEH knowledge introduced earlier into a complete framework for thinking about information security.

1. The main point: attackers do not always need to crack a password—they may persuade you to open the door

Imagine a company with very thorough information-security measures:

• All servers have firewalls.
• Employee accounts are password-protected.
• Only designated staff can read important information.
• All computers receive security patches regularly.

Is the company secure now?

Not necessarily. An attacker might not need to break into any system at all.

They may only need to call an employee:

“Hello, I am an engineer from IT. We have detected a problem with your account. I need you to help verify it, or your account may be suspended.”

If the employee trusts the caller and voluntarily provides a verification code or performs a dangerous action, the existing safeguards may be undermined.

That is the core of social engineering.

Under NIST's definition, social engineering uses deception and trust-building to induce someone to disclose sensitive information, provide unauthorized access, or participate in fraud. NIST Computer Security Resource Center

Today's three most important statements

① Trust is not the same as authentication.

Believing that someone is your manager does not mean they actually are your manager.

② Authentication is not the same as authorization.

Even if the person really is your manager, that does not mean they have authority to ask you for every piece of information.

③ Social engineering is not an isolated attack domain. It can be a key link connecting intelligence gathering, impersonation, unauthorized access and data disclosure.

This third point is central to connecting M09 with the earlier CEH lessons.

2. The most important distinction in social engineering: trust, verification and authorization are different things

This is the most important part of the lesson.

Imagine that a café employee receives a message:

“I am the store manager. I need you to send me the membership list now.”

The employee needs to answer four questions.

Open the original image to enlargeDownload the original SVG

Gate 1: Trust cues

You see the store manager's photo as the sender's LINE profile picture, and the name is correct too.

The sender even provides a voice message that sounds exactly like the store manager.

What does this information prove?

Only this: the sender has presented some characteristics that match the store manager.

These characteristics could be genuine, but they could also come from public information, an account takeover, or AI voice synthesis.

Gate 2: Authentication

Now you need to establish:

“Did the store manager really make this request?”

You can check with the manager using the company's existing directory and previously verified contact details.

However, note that this is identity checking within an organizational process. It does not necessarily provide the same assurance level as a formal information-system authentication mechanism.

In information systems, authentication typically uses passwords, passkeys, certificates or other methods to check whether a user possesses the corresponding proof of identity. NIST Computer Security Resource Center

Gate 3: Authorization

Suppose you have established:

“Yes, this really is the store manager.”

Can you send the membership list immediately?

Not yet.

You still need to check:

“Does the manager have authority to request this particular data transfer?”

For example, company policy may permit sharing members' personal data only through approved systems. Even a genuine request from the manager to send it through a personal cloud drive could violate data-handling rules.

That is the difference between authentication and authorization.

The former asks “Who are you?” The latter asks “What are you allowed to do?”

Gate 4: Least privilege

Even a legitimate, authorized request does not mean you must provide all the data.

If the manager only needs a count of members, you should not simply supply the complete membership database containing names, phone numbers and addresses.

Provide only the permissions and information necessary to complete the work.

This directly connects to CEH M01-06: Security Controls and Defense in Depth.

3. How does social engineering influence people's judgment?

We can understand social engineering through a simplified cause-and-effect sequence:

Build a sense of credibility → influence emotions or judgment → induce a specific action → create a security risk.

For example:

Someone claims to be the head of IT and asks you to provide an account verification code.

Three psychological influences may be present at the same time in this interaction:

Other influences include social proof (“Everyone else has done it”), reciprocity (“I helped you first”), fear and sympathy.

Importantly, these are not stages that must appear in a fixed order in every social-engineering attempt. Nor does any single feature prove that someone is committing fraud.

The question that really matters is:

Are these psychological factors causing us to skip security checks that should normally apply?

What are common forms of social engineering?

Social engineering includes more than phishing emails.

For example, pretexting invents a plausible identity and reason to get someone to cooperate. Baiting uses curiosity or an apparent benefit to entice someone into acting. Tailgating may exploit people's habit of holding a door for a stranger behind them to enter a restricted physical area.

Phishing is one important category. It often uses email, websites, messaging services or voice to induce users to disclose information or perform dangerous actions.

The next lesson, M09-02, explores the differences between phishing, spear phishing and whaling in depth.

4. Connecting CEH knowledge: how might an attacker move from M02 to M09?

Next, we will place the chapters introduced earlier on a single map.

Supplement: these are cross-chapter knowledge connections, not a claim that the reader has completed these chapters. The new route studies M09 before M02, M03, M04 and the subsequent chapters. For unfamiliar material, first understand what it contributes to this map.

Open the original image to enlargeDownload the original SVG

This diagram offers two perspectives.

Perspective A: how do attackers connect different techniques?

Suppose an attacker wants to obtain a company's confidential information.

Step 1: M02 — Footprinting & Reconnaissance

They may learn managers' names, employees' roles and recent company activities from public websites.

This information is not necessarily confidential by itself, but it can be used to design a more convincing impersonation scenario.

Step 2: M09 — Social Engineering

The attacker uses the information to impersonate a manager and asks an employee to supply company account information or download an unknown program.

At this point, the attacker has not necessarily gained access to the system.

Step 3: M06 — System Hacking

If the employee actually hands over login credentials and the attacker successfully passes the relevant security checks, unauthorized account access may occur.

Remember: obtaining a password does not guarantee a successful login. Multi-factor authentication (MFA), conditional access and other security controls may still block the subsequent intrusion.

Step 4: M01-01 — CIA Triad, the three information-security objectives

If the attacker successfully accesses and downloads confidential information, confidentiality is affected.

If they also alter the information, integrity is affected.

If they make a service unavailable for normal use, availability is affected.

This is not an attack chain that inevitably occurs every time. It is an example that helps us analyze cause and effect.

Perspective B: where do M03, M04 and M05 fit?

They provide other technical perspectives.

Network scanning in M03 helps us understand which hosts or services are exposed. Enumeration in M04 reveals more about information provided by DNS, SMB, accounts or services. Vulnerability analysis in M05 helps us assess security gaps in systems, configurations and processes.

Social engineering does not necessarily require scanning or enumeration. However, information obtained through those activities may sometimes support impersonation and deception.

Connecting to M01-05: MITRE ATT&CK

Remember the introduction to MITRE ATT&CK?

Its main purpose is to describe attackers' tactical objectives and the specific techniques used to achieve them.

Social engineering is a broad concept; phishing is one attack technique within it.

For example, MITRE ATT&CK identifies Phishing as T1566, with these sub-techniques:

MITRE places these techniques under the Initial Access tactic. That does not mean every social-engineering attempt successfully establishes initial access. MITRE ATT&CK

When you read security-incident reports in the future, you can therefore ask two questions at the same time:

“What role does this behavior play in the overall attack?”

“Which specific ATT&CK technique does it correspond to?”

This is a practical use of the ATT&CK material in M01-05.

5. A practical scenario: your manager sends an AI voice message asking you to upload documents

Now let us work through a complete simulation.

Suppose you are an administrative employee at a company.

You receive a LINE message in the morning.

The sender uses your manager's photo and sends a voice message that sounds extremely similar to your manager:

“I am in a meeting and need to handle something urgently. Upload the membership data to this website first. I will explain later.”

When you express doubts, the sender adds:

“Then call this number to confirm.”

What should you do now?

Open the original image to enlargeDownload the original SVG

Key concept: independent verification

Independent verification is not about switching communication tools. The verification information must come from a trusted source that does not depend on the suspicious message.

For example:

If the sender gives you a new phone number and you call it, someone answering and claiming to be your manager still does not constitute reliable independent confirmation.

A more reasonable approach is to verify this specific request using the company's existing directory, your manager's known contact details, or the formal internal approval system.

The U.S. FBI has also warned about malicious messages impersonating senior government officials. It advises recipients to independently find reliable contact details to verify identity, rather than relying only on information supplied in the message. FBI

There is still another layer to consider.

Even if the manager personally confirms the request, you must still check whether the data handling follows organizational rules.

This means distinguishing at least the following:

Verify the source of the request → verify authorization for the action → verify the data scope and destination.

For particularly sensitive operations, an organization can add controls such as two-person review. This helps prevent the entire approval mechanism from failing when a single account or communication channel is impersonated or compromised.

What do AI deepfakes change?

AI voice synthesis, generated images and deepfake video can make impersonation more convincing.

But we should not base our security on the assumption that “I should be able to hear whether it is AI.”

Even a request spoken by the real manager may exceed their authority, violate procedures or risk sending data to the wrong place.

Verify whether the action itself is trustworthy, legitimate and approved—not merely whether the media was generated by AI.

6. Connecting to M01-02: how can assets, threats, vulnerabilities and risk help analyze this event?

Now take the role of a security engineer.

Suppose we need to explain the risk of this event to management, rather than simply tell everyone to be careful.

We can use the four concepts from M01-02.

Notice this important distinction:

If the company really lacks a verification process, that is a process vulnerability that might be exploited.

But receiving a suspicious message alone does not prove that the company has this vulnerability, much less that data has already been disclosed.

We need to distinguish:

“What might happen?”

“What was actually observed?”

“Which outcomes are supported by evidence?”

These distinctions are also essential professional judgments in security audits, penetration tests and incident investigations.

7. Connecting to M01-06 and M01-07: how can we actually defend against social engineering?

We previously introduced defense in depth.

This does not mean installing as much security software as possible. It means placing complementary safeguards at different points.

Open the original image to enlargeDownload the original SVG

Layer 1: Prevention

The organization establishes approval procedures for accessing and transferring sensitive information in advance.

For example, it prohibits sending complete membership records directly through personal messaging services.

Layer 2: Verification

When employees receive unusual requests, they verify them through trusted channels.

High-risk operations may need additional approval.

Layer 3: Limitation

Even if an employee is deceived, least privilege, access controls and appropriate data-loss prevention measures can reduce the resulting harm.

Layer 4: Detection & Reporting

Make sure employees know whom to contact when they notice something unusual.

Someone who accidentally clicks a link should not hide the event for fear of being blamed.

Early reporting enables security staff to decide whether they need to terminate sessions, revoke credentials or take other response measures.

Layer 5: Investigation & Recovery

This returns us to incident response in M01-07.

Suppose an employee has already sent the documents. The company needs to investigate:

What information was sent? When did it happen? What was the destination? Were any other accounts or systems affected?

The investigation must be based on records and evidence.

For example:

“A link was clicked” does not mean “malware infection definitely occurred.”

“The account was used to log in” does not mean “the person logging in was definitely the account owner.”

“External sharing permission has been revoked” certainly does not by itself prove that the recipient never downloaded or retained the information.

These distinctions determine the credibility of a security-incident investigation.

8. Bringing today's CEH knowledge together

Looking back at this lesson, we can form this complete chain of concepts:

M02 intelligence gathering → M09 exploitation of trust → possible M06 unauthorized access → impact on M01's CIA security objectives.

On the defensive side, we use:

M01-02 risk analysis → M01-06 security controls → M09 independent verification → M01-07 incident response.

These reduce the likelihood and impact of a successful attack.

These are the two main paths to keep in mind from today's lesson.

Importantly, social engineering and technical intrusion can work together, but not every social-engineering attempt requires a technical vulnerability, and not every attack passes through every chapter.

For a security engineer, the essential skill is not immediately declaring an intrusion after seeing a suspicious email. It is analyzing the relationships among actions, permissions, risk and evidence.

9. Learning check: can you apply the CEH concepts together?

Scenario:

An accountant receives a LINE message using the finance manager's photo.

The sender includes a voice message sounding extremely similar to the manager and demands the immediate transfer of an internal financial report to a new cloud URL.

When the accountant expresses doubt, the sender replies:

“If you do not believe me, call the new number I just gave you. I will personally confirm it.”

Try answering the following:

Question 1 | Authentication

Why is calling back the new phone number provided in the message not reliable independent verification? What would you do?

Question 2 | Authorization

Suppose you use the company's existing contact details and confirm that the finance manager really made the request. Can you now send the report directly? What else must you check?

Question 3 | CEH M01-02

Identify one asset, one threat and one possible vulnerability in this event.

Question 4 | CEH M01-01

If the accountant really sends the confidential report to an unauthorized third party, which CIA Triad security objective is primarily affected? Why?

Question 5 | M01-07 Incident Response

Suppose the accountant only clicked the new URL, without entering account information, downloading files or uploading the report. Which facts do you think are currently established? What additional evidence is needed to judge whether a security incident occurred?

First answer in your own words. I will assess your understanding in turn and identify which concepts you have grasped and which need reinforcement.

Supplement: reference answers are provided below, collapsed by default. Reading an answer does not mean you have answered or understood it. Make your own judgment first, then expand the answer to compare.

Question 1 reference answer | Authentication

No. The new number also came from the suspicious message and may still be controlled by the same impersonator. Use the company’s existing directory or previously verified contact details to check this specific request, using the formal approval process when necessary. Merely switching to a phone does not make verification independent.

Question 2 reference answer | Authorization

Do not send it directly. Check whether the manager has authority to request this transfer, whether the recipient may receive the report, whether the destination is approved and whether you are providing only the information necessary for the work. A genuine manager cannot bypass company rules. High-risk actions can require two-person review under organizational policy.

Question 3 reference answer | Assets, threats and vulnerabilities

An asset is the internal financial report. A threat is someone impersonating the manager to induce the accountant to send it to an unapproved location. A possible vulnerability is a lack of verification or approval procedures for sensitive-data transfers. The last item remains a hypothesis to investigate; receiving the message alone does not prove the company has this weakness.

Question 4 reference answer | CIA security objectives

Primarily confidentiality, because someone who should not receive the report obtains confidential information. The question does not say that information was altered or a service interrupted, so integrity and availability damage must not also be treated as established facts.

Question 5 reference answer | Incident response and evidence

According to the scenario, the accountant clicked the URL and reports not entering account information, downloading files or uploading the report. These actions can still be checked against records. A click does not prove infection, and no manual download does not prove complete safety. Follow organizational reporting procedures, preserve the message and timing, and examine browser redirects and download history, endpoint detections, network connections, and account login/session records for automatic downloads, unusual programs or unauthorized access. If evidence is insufficient, leave the matter under investigation. Do not reopen the suspicious site using a real account to test it.

SVG teaching diagrams for this lesson

The four SVGs created for this lesson are vector images. You can enlarge them for inspection or edit them further with tools such as Inkscape.

Download the four original CEH M09-01 SVG concept diagrams (ZIP)

Further references: NIST definition of Social Engineering and MITRE ATT&CK T1566 Phishing.

Related reading：M01-01 CIA · M01-02 assets and risk · M01-06 security controls · M01-07 incident response · M09-02 phishing