Phishing Campaign: Objectives, Methodology, Spear and Mass Phishing Examples

Phishing remains one of the most formidable and widely used techniques in cyber attacks.

Exploiting human weakness, this method consists of tricking victims into divulging sensitive information, such as credentials, or performing compromising actions, such as clicking on malicious links.

This attack vector, although classic, remains incredibly effective thanks to the diversity of its forms. Phishing is not limited to fraudulent emails. Today, it comes in a variety of forms, depending on the channel used: vishing (or voice phishing) targets victims using phone calls, while smishing exploits text messages as an attack vector.

Fortunately, there are several ways to protect yourself against these attacks. One of the most effective is to raise employee awareness through simulated phishing campaigns. These tests reproduce realistic attack scenarios to assess human vulnerabilities and reinforce employee vigilance in the face of these threats.

In this article, we explore the principles and objectives of a phishing campaign, highlighting the key stages in the methodology. We will also illustrate these assessments through concrete examples, distinguishing between mass phishing campaigns and spear phishing campaigns.

Comprehensive Guide to Phishing Campaigns

What is a Phishing Campaign?

A phishing campaign is a simulated attack designed to trick users into revealing sensitive information or performing compromised actions, such as clicking on a malicious link or downloading an infected file. The aim is to exploit human weakness by playing on trust, urgency or curiosity, in order to gain unauthorised access or compromise a system.

This type of attack is based on social engineering techniques and generally takes the form of fraudulent emails imitating legitimate communications (bank, online services, company).

A phishing campaign can target a wide audience (mass phishing) or be tailored to specific individuals or groups (spear phishing).

Phishing campaigns can be used to assess the vulnerability of users to these threats and to raise awareness among teams of the need to adopt best practices, such as verifying senders, being vigilant about suspicious links and two-factor authentication.

Main Targets of a Phishing Campaign

Phishing campaigns target various profiles within an organisation. Certain teams or employees are particularly exposed because of their access or strategic role.

Understanding these targets enables a better assessment of human vulnerabilities and the adaptation of security policies.

• IT departments are often on the front line. Because of their administrative rights and access to critical systems, they are a prime target. A compromise in this department can enable an attacker to quickly take control of a large part of the network, install malware or steal sensitive data.
• Financial departments handle sensitive data and manage large amounts of money, making them a prime target for fraud such as attempted bank transfers. A phishing campaign targeting these teams often imitates partners or managers, playing on urgency or hierarchical pressure.
• Executives are among the most strategic targets. Because of their privileged access to sensitive information and their hierarchical authority, they are frequently targeted by sophisticated and personalised attacks.
• Finally, all employees, regardless of their role or hierarchical level, are potential entry vectors for attackers. A simple mistake, such as clicking on a link or divulging one’s credentials, can be enough to compromise the entire network.

In short, each profile targeted in a phishing campaign presents specific challenges. These tests can reveal individual and collective weaknesses, assess the effectiveness of awareness policies and better prepare the organisation for real attacks.

Phishing Campaign Methodology

At Vaadata, we carry out two types of phishing campaign:

• Mass phishing campaigns: These campaigns aim to raise awareness among an organisation’s employees. We use generic and non-targeted pretexts, sent by email, to try to steal login credentials. For example, we simulate false security alerts or urgent updates to encourage recipients to enter their details on a fraudulent authentication page.
• Spear phishing campaigns: Here, we develop a tailor-made scenario aimed at a small group of employees. Unlike mass phishing campaigns, we combine different techniques such as SMS phishing (smishing) or voice phishing. The aim is not limited to stealing credentials: it can be to encourage people to pay a false bill or to run malware. This type of attack requires a thorough reconnaissance phase.

Whatever the method, a phishing campaign always begins with a reconnaissance phase. We collect open source technical and human information (OSINT) to analyse the client’s attack surface.

This phase is carried out in black box: we work without any prior information, unless certain elements are provided to us later for the audit. Following this analysis, we propose a list of phishing scenarios tailored to the client’s objectives.

Human reconnaissance

In this phase, the focus is on:

• Potential data leaks, particularly leaks of credentials, which could have an impact on our client.
• Publicly exposed email addresses belonging to employees that could be discovered in black box conditions.
• The client’s Internet activity, particularly on social networks in the case of a spear phishing campaign.

Leaked credentials

Leakage of credentials (username and password) can have serious consequences. A single valid password can be enough for an attacker to gain access to sensitive services, such as a VPN or an email account. With this initial access, he can then extend his attack with complete discretion.

Let’s take an example: an employee mistakenly downloads a malware onto his work computer. This malware is actually an infostealer, designed to steal data, in particular the credentials stored in the browser. If the company’s webmail password is recovered, the attacker can then connect to the victim’s account and send fraudulent emails. These messages will be credible because they are sent from an internal address.

Reusing passwords compounds the problem. If an employee uses the same password on several sites, an identifier compromised on platform X can be reused to access platform Y, for example the company’s webmail.

Two-factor authentication (2FA) limits the risks. Even with the password, an attacker cannot log in without an additional code (Google Authenticator, SMS, etc.). However, some malware goes further and steals session tokens directly. These tokens allow access to an account without the need for a password or 2FA.

If a stealer exfiltrates a valid session token, the attacker can use it to take control of the account, bypassing any additional protection.

This type of attack is still rare, but other techniques can also be used to steal credentials, in particular data leaks from third-party platforms.

Email addresses

Email addresses are essential in any phishing campaign.

For mass phishing campaigns, we work in grey box conditions: the client provides us with the list of addresses to be targeted so that we can raise awareness among all employees in a uniform manner.

For spear phishing campaigns, we can operate in black or grey box. The addresses are not always provided in advance, but can be adjusted with the client according to the needs of the audit.

In all cases, we carry out a black box search to identify public addresses. This enables us to estimate how many addresses a real attacker could recover.

How do we find these addresses?

1. Searching for public addresses
   • Generic addresses such as [email protected] or [email protected] are easy to find.
   • Some employee addresses may be displayed in legal notices or job advertisements.
   • Tools such as hunter.io speed up this process.
2. Deduction of the construction rule
   • From the addresses found, we identify the format used (e.g. [email protected] or [email protected]).
3. Identifying employees
   • We search for names on LinkedIn, job boards or sometimes directly on the company website.
   • Even if a LinkedIn profile is partially hidden, it is often possible to find the full name via the profile URL.
4. Generating and validating addresses
   • Using the names and the construction rule, we generate a list of candidate addresses.
   • We then test their validity via the mail server. A server that returns an error means that the address does not exist.
   • Some servers accept all addresses, even false ones (‘catch-all’), which complicates verification.

Social networks

In a spear phishing campaign, it is essential to create a credible scenario tailored to the target. To do this, an in-depth analysis of the client’s online presence and its employees is carried out.

Social networks are a valuable source of information. They allow us to identify opportunities to build a convincing pretext. This approach, known as SOCMINT (Social Media Intelligence), is based on publicly accessible data.

On LinkedIn, for example, it is common to see partnerships or client-supplier relationships mentioned. An attacker can exploit this information to impersonate a service provider and request payment of a false invoice from a company accountant.

Job offers are another interesting avenue. They can reveal the technologies used internally, such as a specific communication tool. An attacker could then target this application to encourage an employee to enter his or her credentials on a false authentication page.

Recruitment is also a potential attack vector. A hacker could send a fake CV containing malware to a recruiter, taking advantage of the trust placed in unsolicited applications.

If an internal account were to be compromised, the attacker could use it to spread new phishing links to employees, increasing his chances of success. This is why it is crucial to limit the information shared on social networks and to make employees aware of these risks.

Technical reconnaissance

The main objective of technical reconnaissance is to identify web applications used by employees. These applications may be:

• Internal applications, i.e. hosted on a client subdomain (e.g. vpn.koogivi.com).
• Third-party applications, such as Slack or Dropbox. Note that a third-party application can also be hosted on the client’s subdomain.

Identification of internal applications

Internal platforms are identified by searching for domains and subdomains belonging to the client.

The enumeration of domains is largely based on WHOIS data. When a domain name is registered, certain contact details are made public. By analysing these databases, it is possible to identify other domains linked to the same company, thanks in particular to the shared contact information.

Once these domains have been identified, the next step is to discover their subdomains. One of the most effective methods is based on the Certificate Transparency databases.

When a TLS certificate is issued for a domain or subdomain, this information becomes public. By consulting tools such as crt.sh, it is possible to list all the subdomains that have obtained a certificate, thus facilitating the mapping of infrastructures accessible online.

Detection of third-party platforms

One effective method of identifying the third-party solutions used by a company is to examine job advertisements, employees’ LinkedIn profiles, or even the company’s website.

Another approach is to analyse DNS records, particularly TXT records. Some third-party applications require the creation of these records to verify the ownership of a domain. For example, there may be records of type ‘*-domain-verification’, as shown in the example below.

For example, we can see that VAADATA uses tools such as Notion and Slack.

The first TXT record is also relevant. This is the SPF (Sender Policy Framework) policy, which determines which mail servers are authorised to send emails for @vaadata.com addresses. This record suggests that VAADATA uses Outlook as its email client, which is confirmed by the MX record.

Mass Phishing Campaign Example

As mentioned earlier, a mass phishing campaign aims to retrieve login credentials for a third-party application used by the client.

Let’s take a look at the main steps involved in creating a campaign to gain access to the client’s Slack messaging system.

Reconnaissance phase

Here we assume that our client uses Slack. This information can be provided directly by the client if they want us to specifically assess this risk. However, as we saw earlier, it is relatively simple to discover whether an internal or third-party tool is being used.

As regards the email addresses to be targeted, these are generally provided by the client as part of an awareness audit. However, we also apply the enumeration method mentioned earlier in order to compare the results and estimate what proportion of addresses an attacker could discover on his own.

Creation of the phishing scenario

The aim here is to design a convincing email that encourages recipients to log on to a fake authentication page. This stage is based on several key actions:

• Purchase and configuration of a phishing domain: We use a fraudulent domain to send the email and host the phishing site.
• Creation of the email: To maximise the credibility of the attack, we take inspiration from legitimate notifications, adapting them to bypass spam filters and prevent the email from being classified as undesirable.
• Setting up the phishing server: Several techniques can be used to design the fraudulent site. In this particular case, as Slack does not use password authentication but OTP (One Time Password), we prefer phishing in reverse proxy mode. This approach makes it possible to recover the OTP entered by the user and capture the session after authentication, making it easier to compromise the target account.

The phishing email above uses the visual codes of a Slack notification to appear credible. However, there are several clues to the attack:

• The subject (1): It includes a reference to Slack to encourage the message to be opened, while avoiding overly obvious keywords that would trigger spam filters.
• The sender: The email consists of a display name and an email address.
  • The display name (2) can be easily falsified (here it says ‘Slack’).
  • The email address (3) is more difficult to spoof because of the authentication checks (SPF, DKIM, DMARC). Checking the sender’s domain is an essential precaution for detecting a phishing attempt.
• The embedded link (4): The redirection address does not point to slack.com but to a fraudulent domain designed to capture login details. Particular vigilance over the links contained in emails is crucial to avoid this type of attack.

Capture of identifiers and account compromise

If the victim does not pay attention to the aforementioned clues and clicks on the fraudulent link, he will be redirected to a fake Slack authentication page, faithfully reproduced to avoid suspicion.

At this stage, the user still has the opportunity to detect the attack by carefully checking the URL. However, if this check is not carried out and the user enters their email address, Slack will immediately send him an OTP (One Time Password) code to his legitimate email address.

This phase reinforces the credibility of the attack, as the message does indeed come from the official slack.com domain. However, behind this apparently normal interaction lies a man-in-the-middle phishing attack, in which the attacker’s server acts as a proxy between the victim and Slack.

When the victim enters his OTP on the fake page, the attacker captures not only this code, but also the session token generated after authentication. The session token is recovered using Evilginx, an advanced phishing tool for bypassing multi-factor authentication (MFA).

The token is then transferred to Gophish, a platform dedicated to phishing campaigns, which stores it for exploitation.

With the session token in hand, the attacker no longer needs to know the password or the initial OTP: he simply needs to import the token into his browser to gain direct access to the victim’s Slack interface. He can then exploit the access by sending internal messages, exfiltrating sensitive data or extending his attack to other accounts by playing on employees’ trust.

By simply clicking on ‘LAUNCH SLACK’, he can complete the intrusion and act as if he were the legitimate user.

Technical recommendations and awareness-raising following the phishing campaign

Reducing the risk of phishing attacks as far as possible requires a combination of raising staff awareness and implementing technical protection measures:

Raising employee awareness

• Be on the lookout for suspicious emails: Any email requesting a sensitive action (login, download, etc.) should be carefully scrutinised.
• Check the senders’ domains and links: Don’t trust the sender’s name or the subject of the email. Always check the full address and URL of links.
• Warn quickly if in doubt: Report any suspicious emails to prevent others from falling into the trap. A dedicated Slack channel can be useful.
• If you make a mistake, react quickly: If you have submitted your login details on a false page, change your password immediately and disconnect all your sessions.
• Use unique, strong passwords: Avoid reusing your passwords. A password manager can be a good solution.

Technical protection

• Activate two-factor authentication (2FA): Priority for sensitive applications (email, VPN, etc.) and administrator accounts. Physical security keys (YubiKey, passkeys) offer enhanced protection.
• Monitor suspicious connections: Administrative alerts can be activated to report unusual connections (e.g. Google Workspace, Office365).
• Implement SPF/DKIM/DMARC: These email authentication mechanisms reduce the risk of domain spoofing and improve the detection of fraudulent emails.

Spear Phishing Campaign Example

Let’s take a look at an example of a spear phishing campaign. This type of campaign is based on a specific scenario targeting one or a few people.

To appear more credible, the attacker often uses identity theft.

A classic case is the ‘CEO fraud’: an attacker poses as an executive or manager in order to order a fraudulent transfer. In our example, we will target the fictitious company KooGivi.

Reconnaissance

The recon phase of a spear phishing campaign is more in-depth than a traditional attack aimed at stealing credentials. In particular, it includes analysing the activity of the client and its employees on social networks.

LinkedIn, for example, provides valuable information. In addition to the list of employees, the company’s publications can inspire a highly effective attack scenario. It all depends on the imagination of the attacker.

In this case, let’s imagine that we discover the following post:

By analysing Nikola Zaiowski’s profile, we can see that he uses the Symfony framework. Other KooGivi developers also seem to work with this technology.

A relevant scenario might be to invite KooGivi to the next Symfony conference, such as SymfonyLive Berlin 2025. A quick check on their website confirms that the event will be taking place very soon.

Creating the spear phishing scenario

To make the scenario realistic, we need to choose a convincing pretext. The idea is to invite KooGivi developers, in particular Nikola Zaiowski, to the next SymfonyLive conference in Berlin.

However, instead of targeting the developers directly, we’ll be sending an email to the CEO, Zaïa Jefferson, who is in a better position to approve expenses.

The real aim is to get her to accept a fake registration invoice. To do this, we will use a phishing email containing a link to a fake registration site.

To make the attack more credible, we will use the phishing technique in reverse proxy mode to clone the official conference website. In this way, Zaïa will interact with the real site without suspecting that it is passing through our phishing server.

When the registration is validated, we will intercept the request to prevent the KooGivi developers from being registered at the real conference. Zaïa, thinking she had completed the registration, will not be surprised to receive the corresponding invoice.

The site offers several options: continue as a guest, connect with SymfonyConnect or create an account. As we control the traffic between the user and the legitimate site, we have several possible strategies:

• We can remove all the connection options and force the user to choose ‘Continue as a guest’. This approach is technically simpler, as the reverse proxy only handles one scenario.
• Another option is to configure the proxy to capture Zaïa’s SymfonyConnect credentials, if she chooses this method. We could also leave the option of creating an account, which adds another case to manage, but makes the trap more realistic.

In any case, if Zaïa validates the registration, we’ll send her a fake invoice pretending to be the conference organisers.

Running the spear phishing campaign

In concrete terms, the initial phishing email might look like this:

By clicking on the malicious link, Zaïa will be redirected to the fake site. In appearance, it’s the official site, but in reality it’s served via the phishing server, which intercepts all its interactions.

Recommendations following the campaign

The scenario is credible, because the conference actually exists and KooGivi has already taken part in it. The attacker exploits this familiar context to avoid arousing suspicion. Rather than asking directly for money, he proposes registration, making the scam more subtle (although a direct request could sometimes work).

The general recommendations against phishing also apply here, but the key clues remain the domain of the sender and that of the link, which are different from symfony.com.

A best practice to avoid this type of attack is never to click on a link received by email. Instead, search directly for ‘SymfonyLive Berlin’ on Google and go to the official website.

Authors: Benjamin BOUILHAC – Pentester & Amin TRAORÉ – CMO @Vaadata