Uncovering BEC Threats: How Threat Intelligence uses SOC and IR data

Business Email Compromise (BEC) remains a high-impact threat facing organisations across all sectors. Preventing such attacks requires more than traditional perimeter defences; it demands a well-integrated approach between Security Operations Centre (SOC) detection and Incident Response (IR) investigation. When data, insights, and tooling are aligned, detection becomes faster, attribution more precise, and costly remediation efforts can often be avoided.

At the centre of this effort lies the strategic use of Indicators of Compromise (IOCs)—artefacts such as IP addresses, certificates, and notably, computer names. Often undervalued, hostnames serve as critical linking elements between otherwise unrelated events.

Hostnames Matter

An NTLM hostname is the name of the client computer a user is logging in from. For sure, a Threat Actor is free to change the hostname but that is not always the case.

Hostnames in organisations often follow a defined naming convention based on their users or departments. People from outside the organisation may not be aware of those conventions until they breached an organisation, therefore, Threat Actor hostnames tend to stick out.

While IPs, domain names and certificates tend to change frequently, especially in cloud or Virtual Private Server (VPS) environments, hostnames are often consistent. By using hostnames as a complement to other infrastructure traits, links can sometimes be found. Across a few BEC attacks, the Threat Actor has likely unknowingly reused hostnames and unknowingly left a trace for us.

By aggregating and comparing these hostnames and other IOCs across both SOC and IR engagements, it is possible to visualise relationships, in graphs, and uncover patterns. This enables us to find weak links that may otherwise go unnoticed. A single type of IOC might not be enough but in several cases, computer names have served as a way of tying together cases.

Infrastructure Reuse and Attribution

Infrastructure clues continue to play an important role. In some IR cases, shared use of VPS infrastructure helped link multiple engagements. However, environments using large-scale web hosting providers (“web hotels”), infrastructure-based attribution is weaker and requires corroboration through more stable identifiers—such as, again, computer names.

Real world BEC examples

Let’s look at some historic data that explains the general method of linking IOCs.

In Figure 1, we can see two Incident Response cases (marked in red) connected to each other via Threat Actor infrastructure, in this case a VPS service. Threat Actors often use services like VPSs and various relays to “stay under the radar” of the defenders, but sometimes they slip and reuse infrastructure. There are also connections to two SOC cases (marked in orange) through infrastructure.

An interesting thing here is the timing of the incidents. They are happening close to each other, only weeks apart. This is a good example when IR and SOC data can be complemented to build the bigger picture.

Let us look at something more complex…

In Figure 2 above we can see many different IR cases, in red, linked to each other via a supposedly unique NTLM computer name (i.e. WIN-BUNS25TD77J). A NTLM computer name is supposed to be unique, but this is not the case. We see that the name is the same, but the IP addresses differ. Also, the fingerprints, or hashes, for each machine differ. These names come from logs recovered during the IR engagement and follow-up Threat intelligence work.

Links to SOC cases are also found via IP addresses. These links are weak since they are related to large service providers that often mix customers on the same servers, IP segments, and even IP addresses. But since all cases are of the same nature and IOCs overlap, it is likely that the links are solid.

XDR platforms, such as Microsoft’s Defender for Endpoint, often already link attacks to known threat actor groups, such as “Possible Storm-XX …”, which can further feed additional searches for related incidents and cases.

By looking at the dates of SOC incidents, it indicates that the SOC detects early phases of BECs based on the IOCs and TTPs they have available.

Threat Actor Storm-1167

So, what is the Threat Actor called Storm-1167 by Microsoft. As in many criminal cases it is hard to get a good answer, and some attribute breaches without solid data, making false positives a common occurrence. Microsoft’s detailed write-up——outlining attack stages, tactics, and infrastructure closely matched elements observed in our own IR investigations.

Most criminals are motivated by money. And especially in BEC cases, that motivation becomes very clear when Threat Actors try to send false invoices to business partners of the victims.

In most BEC cases that we investigate, there is a certain sequence of events described in previous blog posts in this series (part 1 and part 2).

Threat Actors, being criminals, are often vary of being traced. Therefore, infrastructure used, in operations, is commonly anonymised. Threat Actors may use VPS servers, anonymising proxies, hacked home routers, or other hacked servers. The choice of technology used can be used as a piece to the puzzle making it useful for Threat Intelligence work.

In the current threat landscape, cyber criminals with monetary incentives, tend to be from the eastern parts of Europe. Some sources even say that criminals in Russia are protected from prosecution if they stay away from Russian companies.

Conclusion

The combination of SOC telemetry, IR insights, and external threat intelligence creates a powerful framework for identifying BEC campaigns. While IPs and domains often change, hostnames and certificates remain one of the most reliable artefacts for linking activity across time and infrastructure.

As threat actors grow more agile, defenders must rely on more identifiers—like e.g. NTLM BIOS names—to stitch together the full scope of an attack. Through strategic IOC analysis, especially of such durable artefacts, we can significantly improve detection, reduce response time, and limit operational disruption by feeding information back to the SOC.

---

Part 1 of the BEC blog series
Part 2 of the BEC blog series