TA577 phishing campaign uses NTLMv2 handshakes to steal user credentials/hashes.
In this blog post, Intel-Ops will present the finding of our analysis into the infrastructure behind TA577’s recent phishing campaign utilising Impacket to capture NTLMv2 hashes and steal credentials.
Summary of Activity
TA577, are a Russia-based threat group that have been reported to deliver payloads including Qbot, IcedID, SystemBC, SmokeLoader, Ursnif, and Cobalt Strike in ongoing phishing campaigns since 2020. More recently, they have delivered Pikabot and DarkGate malware. This week, it was reported by Deutsche Telekom CERT https://twitter.com/DTCERT/status/1762808435723145366 that TA577 have been sending .HTML files to make outbound SMB connections to file:// URLs to retrieve a file in an attempt to capture NTLMv2 handshakes.
Analysis
We also began with a notification from one of our students that they had observed this activity. This provided us with some initial indicators to begin our analysis with, referred to as true-positive IPs below.
Additionally, reading the Deutche Telecom tweet mentions that the tool Impacket used in this campaign uses 8-character strings.
Our first rule:
services.smb.session_setup_log.target_name:/.*[A-Za-z0–9]{8}.*/ and services.smb.negotiation_log.server_guid:0000000000000000000000000000000041414141414141414141414141414141 and not services.smb.session_setup_log.target_name:workgroup
The above rule looks for the SMB target_name of 8 alphanumeric strings, as reported by Deutsche Telecom and also adds the Server GUID, finally, we remove target_name’s with “workgroup”. This returns 257 results. (Remove the workgroup for all Impacket servers).
Let’s first take a look at the ASN distribution:
Over half are hosted on the GLOBALWAYS ASN. Additionally there’s some ASNs in here we regularly see used by threat actors for malicious activity, e.g. ALEXHOST, STARK-INDUSTRIES, LIMENET, AS-CHOOPA etc.
Now, we can pivot on the true positive IPs which we know have .html communicating files in VirusTotal.
103[.]124[.]104[.]22
104[.]129[.]20[.]167
204[.]44[.]125[.]68
66[.]63[.]188[.]19
89[.]117[.]2[.]33
155[.]94[.]208[.]137 — only IP with a dns.name: shopsportswearamerica[.]com
If we grab the SSH banner hash from these IPs, they are all the same. So we can add this to the hunt rule:
services.smb.session_setup_log.target_name:/.[A-Za-z0–9]{8}./ and services.smb.negotiation_log.server_guid:0000000000000000000000000000000041414141414141414141414141414141 and not services.smb.session_setup_log.target_name:workgroup and services.banner_hashes="sha256:2bf2033dbf501c6d1f063e64b737f30c2ab11dd1fb2e65a7dd4b2a88c71f23e5"
This returns 27 results, capturing the 6 true positive IPs we know have been used in the campaign. So we have 21 new IPs that may be connected. When sorted by ASN we can see our 6 true positive IPs sit in only 2 ASNs.
The other 2 IPs in these ASNs:
103[.]124[.]104[.]76
89[.]117[.]2[.]34 — buysportswearusa[.]com
As you can see .34 IP has a similar domain to 155[.]94[.]208[.]137, a true positive hit. Let’s break these down to dns.names. (The CyberChef recipe to remove the duplicate urls with “www.” and any “ec2” Amazon urls from the Censys report):
files-adcb[.]com
account-office[.]com
activity-check[.]com
appshare-box[.]com
buysportswearusa[.]com
connect-bsigorup[.]com
docusignservice[.]com
google-gsuitecloud[.]com
hash[.]10dsecurity[.]com
info-zapp[.]com
laboratoriosprovets[.]com
levelbrin[.]com
mail2[.]linkindatafile[.]info
mail2[.]networthfundreport[.]info
matrix[.]lakeys[.]net
primrloock[.]org
redenservices[.]com
services-helpdesk[.]com
sevrice-now[.]com
shopsportswearamerica[.]com
test[.]vryno[.]dev
Interesting that a number of the domains have a similar construction e.g. with “-” within the strings. Bear in mind, of the true positives so far, only 1 has an IP with a corresponding dns.name result.
The other two interesting findings:
From the original 257 IPs, there are 11 IPs with the http response response page which says “We’ll back soon..”, on port 80. There are only these 11 IPs with that banner hash in total on the internet.
Hunt rule:
services.smb.session_setup_log.target_name:/.[A-Za-z0–9]{8}./ and services.smb.negotiation_log.server_guid:
0000000000000000000000000000000041414141414141414141414141414141and not services.smb.session_setup_log.target_name:workgroupand services.http.response.body_hashes="sha1:4ad651cad39078157b64b3c2784fc5c78b8bc547"
From the original 257 IPs, there are 35 IPs with a login panel on port 80:
Only 1 of the IPs from our subset of 27 have this login panel: 54[.]36[.]229[.]25. None of our true positives have this login panel.
Hunt rule:
services.smb.session_setup_log.target_name:/.[A-Za-z0–9]{8}./ and services.smb.negotiation_log.server_guid:
0000000000000000000000000000000041414141414141414141414141414141and not services.smb.session_setup_log.target_name:workgroupand services.http.response.body_hashes:sha1:acbfa5f3e98deff0c4bbe7f652cfd3af13d57fc7
There are 47 IPs in total on the internet with this login panel:
services.http.response.body_hashes:
sha1:acbfa5f3e98deff0c4bbe7f652cfd3af13d57fc7
The true positives either have no http port open/scanned by Censys or return a default Apache page. We can break these results down further by looking for IPs with the SMB matches and IPs running http with a default Apache page and SMB & SSH. It seems of the 6 we know are true positives, 50% have default Apache page and the other 50% don’t have port 80 open/scanned, but some have other ports like Netbios. In our new results we also identify 2 more IP addresses matching on 3 ports: SSH, HTTP, SMB.
And, again, they sit on the same 2 ASNs:
Hunt rule:
services.smb.session_setup_log.target_name:/.[A-Za-z0–9]{8}./ and services.smb.negotiation_log.server_guid:
0000000000000000000000000000000041414141414141414141414141414141and not services.smb.session_setup_log.target_name:workgroupand services.http.response.html_tags="<title>Apache2 Ubuntu Default Page: It works</title>"
After writing this, we saw this post: https://twitter.com/1ZRR4H/status/1762939815715058073 with the following hunt rule for TA577:
same_service(services.smb.negotiation_log.server_guid=”0000000000000000000000000000000041414141414141414141414141414141" and services.smb.negotiation_log.authentication_types=”1.3.6.1.4.1.311.2.2.10" and services.smb.session_setup_log.target_name=/[a-zA-Z0–9]{8}/) and (autonomous_system.asn:142036 or autonomous_system.asn:200019 or autonomous_system.asn:8100 or autonomous_system.asn:207083)
This rule singles out based on ASN and authentication types which we originally used in our hunt rules at the beginning of our searches. The authentication type: 1.3.6.1.4.1.311.2.2.10 is also still found on our 27 IPs in the narrowed rule so rounding by ASNs is really interesting, including the matching domain patterns as not all IPs have a matching domain pattern. We also assessed that these IPs may not have port 80 open or contained a default Apache webpage. However, now that further samples are being submitted to VirusTotal, it appears that these 4 ASNs are standing out as those used by TA577. It looks like you can chop the datasets up many ways and we did so by SSH banner hash, auth types, login panels and ASNs.
We really enjoyed conducting this analysis and comparing findings and results with other researchers.
Results (True Positive Starting IPs — VT communicating .html files)
103[.]124[.]104[.]22
104[.]129[.]20[.]167
204[.]44[.]125[.]68
66[.]63[.]188[.]19
89[.]117[.]2[.]33
155[.]94[.]208[.]137
