The Case For SigParser

• Enhanced detection: Built backend alarms to flag unusual usage patterns that may indicate fraud, with each flagged account reviewed manually by the SigParser team.
• Pattern-based blocking: Implemented systems to detect coordinated mailbox setups that are likely malicious.
• Account disabling with audit support: Created a process to disable suspicious accounts while preserving key metadata, enabling SigParser to support investigations and help victims understand what occurred.
• Payment fraud detection rules: Tightened billing fraud detection rules in Stripe to require 3D Secure 2-factor payment verification on suspicious transactions.
• Mailbox connected anomaly notification: Send automatic alerts when a mailbox is connected to an account that looks suspicious including a simple link to immediately disconnect access and guidance on how to secure their accounts.
• Export restrictions during free trial: Limit data exports to paying customers only, effectively removing access to the freemium offering and reducing exposure.
• Data obfuscation during free trial: Hide email addresses in the SigParser APIs unless the account is paid, preventing scraping by malicious actors attempting to harvest data at scale.

______________________________________________________________________

Court is in session, gang

All rise for the honorable judge “me,” presiding over Huntress Incident Report 1443924, the case of “j.doe@somecorp.onmicrosoft.com” and the use of the SigParser application.

Figure 1: Court is in session!

This blog post covers the details of an anonymized Huntress incident report concerning an identity that displayed extremely high confidence indicators of compromise. Alongside two distinct smoking guns, Huntress also observed the use of a particular Microsoft 365 OAuth application called “SigParser.” This blog explores the facts of the intrusion and hypothesizes as to why a threat actor would install this application during an attack. 

Meet SigParser

Right off the bat, let’s get something out of the way. The SigParser app itself is not dangerous. It is not a malicious application. It does not install malware on your endpoint. In a vacuum, it can do no harm. It is a tool, just like a crowbar. And like a crowbar, the tool itself is neither good nor bad. The use of the tool may have evil intentions behind it, however, and that is a key point to discuss when we talk about Rogue Apps.

Right now, you can go to SigParser’s website, download the tool, install it into your Microsoft 365 tenant, and use it for its intended purpose. And it would be perfectly fine!

Figure 2: SigParser’s landing page

SigParser is an example of what we’ve come to label as “Traitorware”–OAuth applications that are not specifically designed to be evil, but offer some functionality that threat actors seem to love. We keep a list of these apps at the Huntress Rogue Apps GitHub page, which is designed to be a community-driven library that documents observed Rogue App tactics. Other applications that fall into this category include eM Client, CloudSponge, and rclone, among others. Each of these applications is a legitimate utility for M365 designed to fill some role. eM Client, for example, is a convenient email client that helps boost productivity and organize multiple inboxes in a single interface. rclone, on the other hand, proudly proclaims that it is “the Swiss army knife of cloud storage” on its website and offers cloud backup and file transfer utilities. 

Each application that we’ve labeled as Traitorware, while not evil in and of itself, is used by threat actors in the overwhelming majority of instances when we observe the installation of the app. Several of the Traitorware apps have a 95% true positive rate, which presents an interesting detection opportunity. While there are a handful of cases where we identify non-malicious use of the application, these cases are few and far between.

Again, it bears repeating: none of these applications, by themselves, are evil! The existence of a few legitimate cases where an identity is actually using eM Client as their email client application stands testimony to the fact that these apps are simply tools and are neither good nor evil until used for one or the other.

But that begs the question: What is SigParser used for, and why would it be useful to a threat actor? SigParser automatically scans email signatures and calendars to extract contact information and create customer profiles from your emails. It’s primarily used in customer relationship management to build a unified view of customers. In short, it’s used to turn disparate emails into leads and contact profiles.

But how is that useful to threat actors? All will be revealed shortly. With that in mind, let’s review the facts of the case!

The facts of the case

March 12, 2025 – on or about 1705 UTC, Huntress observes user “j.doe@somecorp.onmicrosoft.com” (anonymized name) authenticating from an IP that is geographically located in Arizona. 

Figure 3: Successful authentication with the Axios user agent from a datacenter IP

The user agent of this login is listed as "axios/1.8.2." This is a smoking gun in and of itself, but we’ll get to that in a moment.

The geographical location of this IP address, however, is misleading as the IP in question is hosted within the IP block of a datacenter with the Autonomous System (AS) Name of the provider listed as LLC Baxet. This AS, it turns out, is not necessarily located in the United States. 

Figure 4: Information on the LLC Baxtet AS

This is a prime example of an IP service that leases IP space to ne'er-do-wells. Most identity providers and cyber defense products do not make a determination about if a given IP address is actually residential within its implied geography or if the IP is part of a leasing service like this. While the geographical location implies Arizona, this means that the real user of the IP could be anywhere in the world and is paying to use the datacenter as a proxy. If an IP is tagged as a datacenter, its implied geographical location goes out the window. The datacenter itself might be in the US, but the real user is likely just using it as a proxy. This is one of the reasons why my heat map of all confirmed malicious logins across Huntress-protected partners skews heavily towards the United States and Canada if you do not separate the malicious logins that originated from datacenter infrastructure.

Figure 5: Heatmap of all confirmed Huntress identity incidents by country, excluding tunnel-related IP addresses

The use of the Axios user agent by this login is an extremely high confidence indicator of an active Adversary-in-the-Middle (AitM) attack in progress. This FieldEffect article explains why this is the case, but the summary is that Axios-http is an open-source software library for Node.js and web browsers that gives developers flexible tools for sending, receiving, proxying, and modifying HTTP requests. While the software itself is not malicious (I sense a pattern here…), it is trivial to set up an AitM page that uses this package to capture tokens and harvest credentials from an unsuspecting user.

In my opinion, we could render a guilty verdict on this alone, but let’s continue to examine the other facts first.

At 1706 UTC, just one minute after the initial logins, Huntress observes this same user create a new inbox rule named “.....” (five dots) from a new IP address (91.199.42.99) that is geographically located in New Jersey.

Figure 6: Subsequent creation of an inbox rule

Many would be quick to point out the impossibility of traveling between these two locations, but this assertion misses something critical—both of the IP addresses in question are hosted by data centers. 

Figure 7: IP information on the second IP

It is trivial to change an IP address within this context with the click of a button, no travel necessary! If you do not enrich your telemetry to label VPNs, proxies, and datacenter IPs when trying to make a determination about impossible travel, your hunting methodology is likely to return far more false positives than true positives. Impossible travel as an attribute, by itself, is actually quite a weak indicator of malice. The more important fact here is that we now have two distinct actions from datacenter IP addresses, one of which is the addition of an inbox rule that was completed following authentication from a suspicious AS with a strong indicator of an active AitM attack in progress.

The inbox rule in question is set up to reroute any email containing the domain name of a partner organization into the Deleted Items folder. This is a telltale sign of an attempted business email compromise attack where the threat actor will intercept incoming emails related and attempt to inject themselves into the conversation to score a payday.

Figure 8: Detection data for the inbox rule

We yet again have another smoking gun, but let’s examine the remaining facts of this case to make a final determination. The remaining facts concern the use of the subject of this blog, which is the SigParser application.

Finally, at 1707 UTC, Huntress observes the same identity consent to the SigParser application and a Service Principal for this application is installed in the tenant.

Figure 9: The installation of the SigParser application

For some background on how OAuth applications function in Azure, please see my blog post on the subject or watch the Tradecraft Tuesday on Rogue Apps. A Service Principal is the local entity that handles authentication and authorization for the installed application and acts on behalf of the user that has consented to the application. This essentially means that at this point, SigParser is now installed in the tenant and has the correct authentication and authorization to act as the j.doe user.

Recall that SigParser primarily used to organize mail contacts, export inbox data, and extract information from email signatures. We now get to ask the questions, “Why would a threat actor use this app in particular? What purpose does the app serve during a compromise?” The answer is simple: SigParser can create a new list of potential victims.

Figure 10: The entry for SigParser on the Huntress Rogue App page

After gaining initial access to an identity’s inbox, a threat actor can send emails with immense credibility. Any post-exploitation emails sent from this inbox are now implicitly trusted by the recipients unless further scrutiny is applied. The threat actor now has the perfect platform to launch a spam campaign, additional spear-phishing emails, or any other kind of havoc they intend to wreak. Therefore, SigParser is just a tool to get them a list of new targets. And boy, does it work.

The Huntress SOC swiftly intervened in this particular case and remediated the identity, inbox rules, and the installation of the SigParser application. There were numerous other indicators apart from the SigParser app that would have provided enough evidence to shut the threat actor down. 

Figure 11: The redacted incident report for the inbox rule detection

But after reviewing this case, I couldn’t help but wonder: How many times has our system of detecting OAuth applications caught something that the other detection systems missed?”

As it turns out, about 30% of all Rogue App detections across all Huntress-protected partners are the sole detection for that given identity. In this particular case, there were two extremely high-confidence detections that could each stand by themselves as indication of account takeover. But it’s interesting to see the layers of defense working as intended when we look outside of this specific case. What if the SigParser installation had been the only indicator of compromise? What if the threat actor had evaded our systems of catching Unwanted Access and Shadow Workflows? Indeed, we know this has happened before because a third of all Rogue App signals are the only indication of malice for an identity.

Detection

The SigParser application uses app ID “caffae8c-0882-4c81-9a27-d1803af53a40”. This information is easily available by looking at the installed Enterprise Applications in your tenant’s Azure portal or by calling the Graph API to return all installed service principals. I highly recommend making time to audit your tenant’s OAuth applications for other Rogue Apps. A full list of the apps that we consider to be Traitorware is available free and open to the public at the Rogue Apps page.

Mitigation

While detecting Rogue Apps is fantastic, this is one scenario where mitigation is disproportionately more effective than detection. By default, any identity can install any application into an Azure tenant. Also, by default, any identity can consent to this app’s permissions if those permissions strictly affect the identity’s resources. Azure administrators can lock down user consent for applications and prevent users from installing and consenting to an app without approval from an administrator. I highly recommend this as a mitigation strategy as a way of reducing the attack surface of Rogue Apps in Azure.

Conclusion

The jury has rendered their final verdict! Well, actually, the jury in this case is just me. I get to play judge, jury, and executioner in Traitorware Court. I’m sufficiently convinced that the use of SigParser, in this specific incident, was a strong indicator of threat actor activity. But how does this methodology work at scale? It’s always important to let data guide how we assess these applications, and collecting Traitorware data at scale has revealed each app’s likelihood of benign use vs. malicious use.

As a relatively new addition to the Traitorware list, SigParser has been observed 41 times total at the time of writing this blog. These instances are either enumerated from a tenant during onboarding or identified after observing a Service Principal installation in a tenant. This places it as the lowest Traitorware application by volume alone. To put it into perspective, our number one Traitorware application by volume is eM Client with over 2,800 observed installations. More importantly, when we analyze the instances where we’ve identified a Traitorware application and the partner has informed us that it is a false positive, we see stark differences between these two apps.

eM Client, on one hand, sits at a ~97% true positive rate with over 28,000 observed installations:

Figure 12: Accepted vs rejected rate for eM Client

While SigParser, with far less data to make the determination, sits around 88%:

Figure 13: Accepted vs. rejected rate for SigParser

Time will tell if SigParser’s true positive rate will normalize, but even today, we can make a moderately confident determination that SigParser may be used legitimately more often than other apps like eM Client. This highlights the complexity of detection in the identity space and reminds me of similar detection conundrums like hunting for malicious RMMs and LOLBAS. Not every use of SigParser or eM Client or any of the other Traitorware applications is an immediate indicator of malice, but the data shows that the use of any of these apps can be a key indicator of malice in an overwhelming majority of instances.

With regards to Huntress Incident Report 1443924, I hereby sentence this identity to remedial security awareness training (SAT), a credential rotation, strict enforcement of MFA, and a promise to be politely suspicious of all links in their inbox. Hey, hackers are gonna hack but you gotta make sure you don’t make their job any easier! We caught them this time but remember to keep your head on a swivel.

Court dismissed! Bring in the dancing lobsters.