WAF bypass Tool is an open source tool to analyze the security of any WAF for False Positives and False Negatives using predefined and customizable payloads. Check your WAF before an attacker does. WAF Bypass Tool is developed by Nemesida WAF team with the participation of community.
How to run
It is forbidden to use for illegal and illegal purposes. Don't break the law. We are not responsible for possible risks associated with the use of this software.
Run from Docker
The latest waf-bypass always available via the Docker Hub. It can be easily pulled via the following command:
# docker pull nemesida/waf-bypass # docker run nemesida/waf-bypass --host='example.com'
'--proxy' (--proxy='http://proxy.example.com:3128') - option allows to specify where to connect to instead of the host.
'--header' (--header 'Authorization: Basic YWRtaW46YWRtaW4=' --header 'X-TOKEN: ABCDEF') - option allows to specify the HTTP header to send with all requests (e.g. for authentication). Multiple use is allowed.
'--user-agent' (--user-agent 'MyUserAgent 1/1') - option allows to specify the HTTP User-Agent to send with all requests, except when the User-Agent is set by the payload ("USER-AGENT").
'--block-code' (--block-code='403' --block-code='222') - option allows you to specify the HTTP status code to expect when the WAF is blocked. (default is 403). Multiple use is allowed.
'--threads' (--threads=15) - option allows to specify the number of parallel scan threads (default is 10).
'--timeout' (--timeout=10) - option allows to specify a request processing timeout in sec. (default is 30).
'--json-format' - an option that allows you to display the result of the work in JSON format (useful for integrating the tool with security platforms).
'--details' - display the False Positive and False Negative payloads. Not available in JSON format.
'--exclude-dir' - exclude the payload's directory (--exclude-dir='SQLi' --exclude-dir='XSS'). Multiple use is allowed.
Payloads
Depending on the purpose, payloads are located in the appropriate folders:
When compiling a payload, the following zones, method and options are used:
URL - request's path
ARGS - request's query
BODY - request's body
COOKIE - request's cookie
USER-AGENT - request's user-agent
REFERER - request's referer
HEADER - request's header
METHOD - request's method
BOUNDARY - specifies the contents of the request's boundary. Applicable only to payloads in the MFD directory.
ENCODE - specifies the type of payload encoding (Base64, HTML-ENTITY, UTF-16) in addition to the encoding for the payload. Multiple values are indicated with a space (e.g. Base64 UTF-16). Applicable only to for ARGS, BODY, COOKIE and HEADER zone. Not applicable to payloads in API and MFD directories. Not compatible with option JSON.
JSON - specifies that the request's body should be in JSON format
BLOCKED - specifies that the request should be blocked (FN testing) or not (FP)
Except for some cases described below, the zones are independent of each other and are tested separately (those if 2 zones are specified - the script will send 2 requests - alternately checking one and the second zone).
For the zones you can use %RND% suffix, which allows you to generate an arbitrary string of 6 letters and numbers. (e.g.: param%RND=my_payload or param=%RND% OR A%RND%B)
You can create your own payloads, to do this, create your own folder on the '/payload/' folder, or place the payload in an existing one (e.g.: '/payload/XSS'). Allowed data format is JSON.
API directory
API testing payloads located in this directory are automatically appended with a header 'Content-Type: application/json'.
MFD directory
For MFD (multipart/form-data) payloads located in this directory, you must specify the BODY (required) and BOUNDARY (optional). If BOUNDARY is not set, it will be generated automatically (in this case, only the payload must be specified for the BODY, without additional data ('... Content-Disposition: form-data; ...').
If a BOUNDARY is specified, then the content of the BODY must be formatted in accordance with the RFC, but this allows for multiple payloads in BODY a separated by BOUNDARY.
Other zones are allowed in this directory (e.g.: URL, ARGS etc.). Regardless of the zone, header 'Content-Type: multipart/form-data; boundary=...' will be added to all requests.
This tool is a command line utility that allows you to convert any binary file into a QRcode GIF. The data can then be reassembled visually allowing exfiltration of data in air gapped systems. It was designed as a proof of concept to demonstrate weaknesses in DLP software; that is, the assumption that data will leave the system via email, USB sticks or other media.
The tool works by taking a binary file and converting it into a series of QR codes images. These images are then combined into a GIF file that can be easily reassembled using any standard QR code reader. This allows data to be exfiltrated without detection from most DLP systems.
How to Use
To use QRExfiltrate, open a command line and navigate to the directory containing the QRExfiltrate scripts.
Once you have done this, you can run the following command to convert your binary file into a QRcode GIF:
Where <inputfile> is the path to the binary file you wish to convert, and <outputfile>, if no output is specified output.gif used is the path to the desired output GIF file.
Once the command completes, you will have a GIF file containing the data from your binary file.
You can then transfer this GIF file as you wish and reassemble the data using any standard QR code reader.
Prerequisites
QRExfiltrate requires the following prerequisites:
qrencode
ffmpeg
Limitations
QRExfiltrate is limited by the size of the source data, qrencoding per frame has been capped to 64 bytes to ensure the resulting image has a uniform size and shape. Additionally the conversion to QR code results in a lot of storage overhead, on average the resulting gif is 50x larger than the original. Finally, QRExfiltrate is limited by the capabilities of the QR code reader. If the reader is not able to detect the QR codes from the GIF, the data will not be able to be reassembled.
The decoder script has been intentionally omitted
Conclusion
QRExfiltrate is a powerful tool that can be used to bypass DLP systems and exfiltrate data in air gapped networks. However, it is important to note that QRExfiltrate should be used with caution and only in situations where the risk of detection is low.
That’s a wrap for Pwn2Own Vancouver! Contestants disclosed 27 unique zero-days and won a combined $1,035,000 (and a car)! Congratulations to the Masters of Pwn, Synacktiv (@Synacktiv), for their huge success and hard work! They earned 53 points, $530,000, and a Tesla Model 3.
Team Synacktiv: Eloi Benoist-Vanderbeken, David Berard, Vincent Dehors, Tanguy Dubroca, Thomas Bouzerar, and Thomas Imbert. They also receive a $25,000 bonus and Platinum status in 2024.
Welcome to Day 3 of Pwn2Own Vancouver 2023. We’ll be updating this blog in real time as results become available. For this year’s event, each round will receive the full payout for unique entries.
SUCCESS - Kyle Zeng from ASU SEFCOM used a double free bug to exploit Ubuntu Desktop. He earns $30,000 and 3 Master of Pwn points.
FAILURE - STAR Labs was unable to get their exploit of Microsoft Teams working within the time allotted.
SUCCESS - Thomas Imbert (@masthoon) from Synacktiv (@Synacktiv) used a UAF against Microsoft Windows 11. They earn $30,000 and 3 Master of Pwn points.
SUCCESS - Mingi Cho of Theori used a UAF against Ubuntu Desktop. They earn $30,000 and 3 Master of Pwn points.
SUCCESS - STAR Labs (@starlabs_sg) used an uninitialized variable and UAF against VMWare Workstation. They earn $80,000 and 8 Master of Pwn points.
COLLISION - Bien Pham (@bienpnn) of Qrious Security successfully targeted Ubuntu Desktop, but the exploit was previously known. They still earn $15,000 and 1.5 Master of Pwn points.
Mimicry is a security tool developed by Chaitin Technology for active deception in exploitation and post-exploitation.
Active deception can live migrate the attacker to the honeypot without awareness. We can achieve a higher security level at a lower cost with Active deception.
Safety first! Learn everything about your company’s IT vulnerabilities, how to protect yourself from ransomware attacks and which backups are essential at our X-perience Day Security. Come by our office in Neu-Ulm, enjoy coffee and cake while we show you how to take your IT security to the next level When: 29.03.2023 @ 13:00 – […]
CVE pending – pending – Vulnerable software PasswordSafe 8.12.1.22757 (according to the manufacturer, the current version 8.13.9.26689 was also affected at that time) Vulnerability Weak cryptography Timeline
A joint walk and maximum input - this is what distinguishes the walk show of the TÜV SÜD Academy.
Florian Hansemann was invited as a security expert and presented concrete options for action for private individuals and companies.
Welcome to this week’s edition of the Threat Source newsletter.
After asking ChatGPT to write the newsletter for me two weeks ago, I was tempted to have Google’s Bard do the same, but I resisted making this the newsletter’s new gimmick.
Instead, I wanted to write about another tech giant — Meta.
The company recently doubled down on a threat to remove news links and sharing from its Facebook and Instagram platforms if Canada passes its proposed Online News Act, or bill C-18. The proposed legislation would compel companies like Meta and Google to sign agreements with Canadian news organizations that would pay them each time a user clicks on a news link through one of their platforms (i.e., via a shared link on Facebook or a Google search result).
If Facebook stops users from sharing news links on their pages, it could be a net positive. Facebook users are notoriously the biggest offenders for sharing fake news and misinformation. A May 2020 study published in Nature Human Behavior found that Facebook pointed users to fake news websites during the 2016 presidential election at a higher rate than any other social media platform.
A separate study from Harvard found that during the first few months of 2020, the rate of user engagement with fake news to mainstream news stories was 1:3.5, and the International Communications Association found via a study of social media users that, “sharing countermedia content on Facebook is positively associated with ideological extremity and negatively associated with trust in the mainstream news media.”
If Instagram, Facebook and other social media sites were to follow along with this with Canada (Google already started quietly removing news links from its search engine last month in protest of the Online News Act), I think it could go a long way toward fighting disinformation. If users can’t get their news through social media, they may be forced to seek out information independently rather than blindly clicking “share” on Great Aunt Betty’s post, which is just a bad parody from the Babylon Bee.
I also would be remiss to not discuss the benefits this legislation would possibly have on newsrooms in Canada. As a former journalist, and someone who was worried about being laid off 24/7 in my previous jobs, it’s a financial struggle out there right now for legitimate news organizations. Online advertising isn’t what it once was, so many outlets are being forced to pivot to hard paywalls or rely on clickbait articles that don’t deliver any news. If this presents a new way to fund legitimate journalism, especially if the only financial burden falls on the richest companies in the world, it could go a long way to sustaining newsrooms.
Just because something becomes legal in Canada doesn’t mean other countries are going to be adopting the same rules any time soon. But if news sharing does suddenly go away on Facebook in Canada, maybe it will force all of us to think about where we’re really consuming our news from and how we consumed news even just 15 years ago.
The one big thing
We’re still reminding people to update their Microsoft Outlook clients as soon as possible after the disclosure of CVE-2023-23397. Attackers have reportedly been exploiting this vulnerability since last year, though a fix is available now through Microsoft. Adversaries could manipulate a targeted system into supplying the user’s Net-NTLMv2 hash to the attacker, which can then be used in NTLM Relay attacks against other systems.
Why do I care?
Multiple sources, including Microsoft itself, have confirmed that this vulnerability is being used in the wild. Plus, users don’t even have to open the email or any malicious attachments to trigger this vulnerability, the specially crafted email just has to hit the target’s Outlook inbox. This is a high-severity, low-complexity vulnerability everyone should be patching for if they haven’t already.
So now what?
Microsoft has released a patch that should be applied, but Talos also has several layers of detection and protection available. If, for some reason, your organization cannot apply this patch, Microsoft also provided a few mitigation options, including adding users to the Protected Users Security Group to prevent the use of NTLM as an authentication mechanism as well as blocking port TCP/445 outbound from your network to block the NTLM messages from leaving the network.
Top security headlines of the week
The popular dark web site BreachForums shut down this week after the FBI arrested its main admin. This is the latest in a string of law enforcement wins against cybercrime groups, who also brought down the Hive ransomware gang in January and RaidForums, BreachForums’ predecessor, last year. The site’s administrator, who goes by the username “Pompompurin,” also claimed responsibility for a data breach of the FBI’s email system in November 2021. Cyber criminals commonly used BreachForums to buy and sell stolen databases of information and had been at the center of recent high-profile data breaches, including this month's attack on DC Health Link that led to the theft of sensitive information belonging to several Congressional representatives. (Krebs on Security, Axios)
Google’s security research team discovered several zero-day vulnerabilities in certain Samsung chips that leave many Google smartphones and other wearable devices vulnerable. There are four critical flaws that could compromise affected devices “silently and remotely” over the cellular network, according to Google Project Zero’s blog post on the matter. An attacker could exploit those vulnerabilities to “remotely compromise a phone at the baseband level with no user interaction and require only that the attacker know the victim’s phone number.” Google says it was forced to disclose the vulnerabilities without a patch for many of the affected devices because Samsung did not adhere to its 90-day deadline to issue a fix. (TechCrunch, Google Project Zero)
TikTok’s CEO was scheduled to appear before a U.S. Congressional committee Thursday to discuss the popular app’s data security and privacy policies as there are renewed calls among the federal government to block the app. Prepared statements from CEO Shou Zi Chew showed that he would tout TikTok’s $1.5 billion investment in storing U.S. users’ information on Oracle servers and allow outside monitors to inspect the company’s source code. U.S. regulators have reportedly threatened to ban TikTok unless the company’s Chinese owners sell their stake, though the actual mechanics of blocking and de-listing the app are more complicated than they seem on the surface. (ABC News, New York Times)
Russia – Ukraine Conflict and Its Impact on the Cyber Threat Landscape Bottom Line Up Front (BLUF) Russia’s attempt to annex parts of Ukraine created a broader contention between nations and drew western nations into the conflict. The sabotage of the Russian Nordstream 1 & 2 pipelines may be an act of further escalation and …
Welcome to Day 2 of Pwn2Own Vancouver 2023! We’ll be updating this blog in real time as results become available. We’re excited to say that all unique winning entries will receive the full payout during this year’s contest. We’ll update this blog throughout the day with results as they come in.
SUCCESS / COLLISION - Thomas Imbert (@masthoon) and Thomas Bouzerar (@MajorTomSec) from Synacktiv (@Synacktiv) demonstrated a 3-bug chain against Oracle VirtualBox with a Host EoP. One bug was previously known. They still earn $80,000 and 8 Master of Pwn points.
SUCCESS - @hoangnx99, @rskvp93, and @_q5ca from Team Viettel (@vcslab) used a 2-bug chain in their attempt against Microsoft Teams. They earn $75,000 and 8 Master of Pwn points.
SUCCESS - David Berard (@_p0ly_) and Vincent Dehors (@vdehors) from Synacktiv (@Synacktiv) used a heap overflow and an OOB write to exploit Tesla - Infotainment Unconfined Root. They qualify for a Tier 2 award, earning $250,000 and 25 Master of Pwn points.
SUCCESS - dungdm (@_piers2) of Team Viettel (@vcslab) used an uninitialized variable and a UAF bug to exploit Oracle VirtualBox. They earn $40,000 and 4 Master of Pwn points.
SUCCESS - Tanguy Dubroca (@SidewayRE) from Synacktiv (@Synacktiv) used an incorrect pointer scaling leading to privilege escalation on Ubuntu Desktop. They earn $30,000 and 3 Master of Pwn points.
That wraps up Day 2 of Pwn2Own Vancouver 2023! We awarded $475,000 for 10 unique zero-days during the second day of the contest. We’ll continue posting results and videos to Twitter, YouTube, Mastodon, LinkedIn, and Instagram, so follow us on your favorite flavor of social media for the latest news from the event.
Today, leading cybersecurity service provider VerSprite and security training leader AppSecEngineer announce a partnership to operationalize security training. The joint effort will result in a comprehensive full-stack security training program to equip organizations to handle any security challenges that may arise. “VerSprite has always taken a risk-first approach to cybersecurity, even inventing the PASTA risk methodology,” …
Veeam has recently released an advisory for CVE-2023-27532 for Veeam Backup and Replication which allows an unauthenticated user with access to the Veeam backup service (TCP 9401 by default) to request cleartext credentials. Others, including Huntress, Y4er, and CODE WHITE , have provided insight into this vulnerability. In this post, we hope to offer additional insights and release our POC (found here) which is built on .NET Core and capable of running on Linux.
Examining the Vulnerable Port
We first determine what application is using vulnerable port 9401.
Find application using port 9401
Now we can begin to reverse engineer the Veeam Backup Service. By default, we find the service binary and its associated assemblies in C:\Program Files\Veeam\Backup and Replication\Backup. The log file for the backup service is located at C:\ProgramData\Veeam\Backup\Svc_VeeamBackup.log. Searching for the port in question in the log file gives a string that we can search for in the binary.
Find port in log file
InitSslServerChannel
Next we dig into the call to CreateService and eventually find ourselves at a private constructor for CRemoteInvokeServiceHolder:
CRemoteInvokeServiceHolder
The use of ServiceHost, NetTcpBinding, and AddServiceEndpoint gives us enough context to know that this app is hosting a Windows Communication Foundation (WCF) service. The services exposes the IRemoteInvokeService interface to the client and the interface is implemented by CVbRestoreServiceStub on the server side.
The use of NetTcpBinding tells us that this service is using a binary protocol built on TCP intended for WCF to WCF communication. This restricts our client implementation to a .NET language as it would be rather difficult to write a custom WCF binary parser. We do not want our POC to be restricted to running on Windows so we will use .NET core for our POC.
Constructing a WCF Client
Before we are able to create a client, we need the service interface definition. Based on previous research, we know that we need a few credential based methods from the DatabaseManager scope. We end up with the following definition:
Now we can try to connect to the service:
Our first attempt is met with the following error:
/home/dev/RiderProjects/Veeam_CVE-2023-27532/CVE-2023-27532/bin/Debug/net6.0/CVE-2023-27532 net.tcp://192.168.1.139:9401/
Unhandled exception. System.ServiceModel.ProtocolException: The requested upgrade is not supported by 'net.tcp://192.168.1.139:9401/'. This could be due to mismatched bindings (for example security enabled on the client and not on the server).
If we look back at CRemoteInvokeServiceHolder, we see that the NetTcpBinding was created with parameter "invokeServiceBinding". We can find the configuration parameters for this binding in Veeam.Backup.Service.exe.config:
Veeam.Backup.Service.exe.config
With this information, we can update our POC. After disabling certificate validation and setting the correct DNSIdentity, we have the following:
Running the POC we get:
/home/dev/RiderProjects/Veeam_CVE-2023-27532/CVE-2023-27532/bin/Debug/net6.0/CVE-2023-27532 net.tcp://192.168.1.139:9401/
Unhandled exception. System.ServiceModel.FaultException: Data at the root level is invalid. Line 1, position 1.
This indicates that we were able to successfully invoke the service. The error is a result of us passing invalid XML. Now we can begin to figure out how to extract credentials from this API.
Extracting Credentials
Based on previous research, we know that we can invoke CredentialsDbScopeGetAllCreds to get a binary blob containing credential information. If we look at the implementation of ExecuteCredentialsDbScopeGetAllCreds we see that this blob is a serialized C# object created by Veeam’s custom CProxyBinaryFormatter.
ExecuteCredentailsDbScopeGetAllCreds
If we dump this data to a file we can see that there is username and password information, but it is not immediately obvious how to parse this information out of the binary blob. We don’t want to reimplement Veeam’s custom serialization class and also don’t want to have to reference their assemblies. So what can we do? It looks like there are some easily parseable guids prefixed by $.
CredentialsDbScopeGetAllCreds output
We see that these guids match the id used for Credentials in the Veeam database:
Credentials in Veeam database
We can now use the CredentialsDbScopeFindCredentials endpoint to get one credential at a time. Our code to extract the guids looks like:
The output from CredentialsDbScopeFindCredentials is still a binary blob, but at least we can work with one Credential at a time now instead of a list. We still have the problem of having to parse out the usernames and passwords. Luckily, we found a Stackoverflow post detailing how to use a custom serializer to get object properties as key value pairs. We can now extract the usernames an passwords with ease.
In conclusion, CVE-2023-27532 allows an unauthenticated user with access to the Veeam backup service to request cleartext credentials. We have examined the vulnerable port, reverse engineered the Veeam Backup Service, and constructed a WCF client using .NET core. We have also shown how to extract credentials from the Veeam database by invoking the CredentialsDbScopeGetAllCreds and CredentialsDbScopeFindCredentials endpoints. Finally, we have released our POC on Github, which is built on .NET core and capable of running on Linux, making it accessible to a wider audience. It is important to note that this vulnerability should be taken seriously and patches should be applied as soon as possible to ensure the security of your organization.
In the months leading up to Russia’s invasion of Ukraine, Cisco and Talos did everything we could to support our friends, partners and colleagues, who were facing a reality unlike anything that can be found in any technical training manual, SOP or SLA.
Once the invasion began, there was an influx of people across Cisco and Talos who wanted to help. That led to the development of an internal Ukraine task unit, which has become a prototype for how we can respond to future global events that are likely to have significant, ongoing cyber implications.
We also deployed and managed Cisco Secure products within a variety of Ukrainian organizations, and refocused parts of our workforce to monitor and detect threats against critical infrastructure. Much of this work continues today as part of an ongoing, comprehensive wartime effort to protect the people of Ukraine and enhance the resilience of Ukrainian organizations.
Many people have asked about our task unit, and what we do on a day-to-day basis to help organizations in Ukraine detect and respond to attacks against their critical infrastructure.
As you can probably imagine, there isn’t a typical day.
One of the key outcomes of the task unit, which has been wonderful to witness, is that people without a technical threat hunting background can add a great deal to our efforts. The power in diversity of thought and experience is explicit in our efforts to support Ukraine.
We decided to encapsulate this difficult, but important, work in the form of a graphic novel, which explores some of the themes we touched on in the documentary. Read it below or click here.
As of April 20, 2023, we are decommissioning SenderBase.org and any attempts to visit that web page will fail.
Talos Intelligence’s website (TalosIntelligence.com) has served as the replacement for SenderBase.org for many years, with TalosIntelligence.com providing the same information as SenderBase.org once did. Since that time, visitors to SenderBase.org have been automatically redirected to TalosIntelligence.com, and the redirect from SenderBase.org is finally being removed on April 20, 2023. After that, attempts to visit SenderBase.org will fail.
Any users still utilizing bookmarks or links pointing to Senderbase.org should update these to ensure they still work appropriately.
By Aleksandar Milenkoski, Juan Andres Guerrero-Saade, and Joey Chen, in collaboration with QGroup
Executive Summary
In Q1 of 2023, SentinelLabs observed initial phases of attacks against telecommunication providers in the Middle East.
We assess that this activity represents an evolution of tooling associated with Operation Soft Cell.
While it is highly likely that the threat actor is a Chinese cyberespionage group in the nexus of Gallium and APT41, the exact grouping remains unclear.
SentinelLabs observed the use of a well-maintained, versioned credential theft capability and a new dropper mechanism indicative of an ongoing development effort by a highly-motivated threat actor with specific tasking requirements.
Overview
In collaboration with QGroup GmbH, SentinelLabs recently observed initial threat activities targeting the telecommunication sector. We assess it is highly likely that these attacks were conducted by a Chinese cyberespionage actor related to the Operation Soft Cell campaign.
The initial attack phase involves infiltrating Internet-facing Microsoft Exchange servers to deploy webshells used for command execution. Once a foothold is established, the attackers conduct a variety of reconnaissance, credential theft, lateral movement, and data exfiltration activities.
The deployment of custom credential theft malware is central to this new campaign. The malware implemented a series of Mimikatz modifications on closed-source tooling. This post details the multi-component architecture and functionality of a sample, referred to as mim221.
We assess that mim221 is a recent version of an actively maintained credential theft capability upgraded with new anti-detection features. The use of special-purpose modules that implement a range of advanced techniques shows the threat actors’ dedication to advancing its toolset towards maximum stealth. These techniques include
in-memory mapping of malicious images to evade EDR API hooks and file-based detections
surgically terminating Event Log threads instead of the host process to inhibit logging without raising suspicions
staging a credential theft capability in the LSASS process itself by abusing native Windows capabilities.
Version numbers and build timestamps indicate a maintained software project by designated developers. Closer analysis reveals an element of pragmatism in that the threat actors use modified publicly available code to achieve their goals.
In terms of attribution, the tooling suggests an immediate link to the ‘Operation Soft Cell’ campaign but remains slightly vague on the specific threat actor. That campaign has been publicly associated with Gallium and possible connections to APT41 have been suggested by the use of a common code signing certificate and tooling that shares code similarities. APT41 is also known to target telecommunication providers.
Given previous target and TTP overlaps, and an evident familiarity with victim environments, we assess with medium-confidence that Gallium is involved. However, we also recognize the possibility of closed-source tool-sharing between Chinese state-sponsored threat actors, and the possibility of a shared vendor or digital quartermaster.
Regardless of clustering specifics, this finding highlights the increased operational tempo of Chinese cyberespionage actors and their consistent investment in advancing their malware arsenal to evade detection.
Infection Vector and Initial TTPs
As initial attack indicators, we observed command execution through webshells on compromised Microsoft Exchange server deployments. The threat actors used C:\MS_DATA as their main working directory for storing malware and staging data for exfiltration. Noting that the Microsoft TroubleShootingScript toolset (TSSv2) uses C:\MS_DATA for storing log files, we suspect that its use as a working directory is an attempt to make malicious file system activities look legitimate.
After establishing an initial foothold, the threat actor conducts reconnaissance like querying user and network information using a variety of tools. For example, the attackers used dsquery and query to obtain information about Active Directory objects, including user information, and Remote Desktop user sessions. They also used the Local Group (LG) tool to enumerate all local groups and members in a domain.
"cmd" /c cd /d C:\MS_DATA\&dsquery * -limit 0 -filter
"cmd" /c cd /d C:\MS_DATA\&dsquery * -limit 0 -filter "&(objectClass=User)(objectCategory=Person)" -attr objectSID sAMAccountName displayName mail memberOf >da.back&cd
"cmd" /c cd /d c:\windows\system32\inetsrv\&query user&cd
"cmd" /c cd /d C:\MS_DATA\&lg.exe \\[IP ADDRESS] -lu >169.txt&cd
The attackers then check connectivity with both the Internet and specific local machines of interest.
"cmd" /c cd /d c:\windows\system32\inetsrv\&ping 8.8.8.8 -n 1&cd
"cmd" /c cd /d c:\windows\system32\inetsrv\&ping -n 1 [IP ADDRESS/HOSTNAME]&cd
They also retrieve networking information, like network adapters, specific machines, and network services like Remote Desktop Protocol (RDP).
"cmd" /c cd /d C:\MS_DATA\&ipconfig /all&cd
"cmd" /c cd /d c:\windows\system32\inetsrv\&net use&cd
"cmd" /c cd /d c:\windows\system32\inetsrv\&netstat.exe -nob
"cmd" /c cd /d c:\windows\system32\inetsrv\&netstat -aon |find "3389"&cd
"cmd" /c cd /d C:\MS_DATA\&netstat -aon |find "[IP ADDRESS]"&cd
The threat actor made use of the native makecab tool to compress information gathered for exfiltration.
"cmd" /c cd /d C:\MS_DATA\&makecab da.back d.zip >1.txt&cd
For lateral movement, the attackers made use of the PsExec tool and the net use command for accessing shared resources on remote machines.
"cmd" /c cd /d C:\MS_DATA\&net use \\[IP ADDRESS] [PASSWORD] /u:[DOMAIN]\[USERNAME]
A Penchant for Credential Theft
In order to steal credentials, the attackers employ custom modified versions of Mimikatz, including an executable named pc.exe.
Mimikatz publicly available code (top); strings from a Mimikatz modification (bottom)
The pc.exe executable stages the execution of three other components that ultimately result in stealing credentials from the Local Security Authority Subsystem Service (LSASS) process.
We refer to the four component chain as ‘mim221’ based on the version number that the tool displays (2.2.1).
We observed the threat actors deploying individual chunks of pc.exe in the working directory and merging these into pc.exe using the type command.
pc.exe file chunks
We noticed that the attackers ceased their activities after stealing credentials. This could indicate a multi-phase attack strategy, where the deployment of backdoors and further persistence mechanisms is carried out separately after credential theft has ensured continued access. The intrusions were detected and interrupted before the attackers could carry out further phases, such as deploying backdoors.
mim221
The architecture of mim221 consists of four components: the pc.exe Windows executable, and the AddSecurityPackage64.dll, pc.dll, and getHashFlsa64.dll DLLs contained therein.
mim221 execution overview
mim221 Component
Size
Compilation timestamp
pc.exe
502 KBs
Thu Jun 09 08:02:12 2022 (UTC)
AddSecurityPackage64.dll
119 KB
Thu Jun 09 08:01:46 2022 (UTC)
pc.dll
297 KB
Tue Jun 07 16:55:05 2022 (UTC)
getHashFlsa64.dll
216 KB
Fri May 27 20:56:26 2022 (UTC)
pc.exe
The main binary executed by the threat actor is pc.exe. It decrypts AddSecurityPackage64.dll and pc.dll, stores pc.dll on the file system, and then loads and executes AddSecurityPackage64.dll by invoking its exported function, pathAddPackage.
The execution of pc.exe requires a password supplied by the operator (in this case, [email protected]#$C), which the operator provides through the key command-line parameter.
pc.exe decrypts AddSecurityPackage64.dll and pc.dll using the AES encryption algorithm, providing the operator-provided execution password as an initialization vector.
pc.exe loads and executes the decrypted AddSecurityPackage64.dllusing reflective image loading. This technique involves first mapping a Windows PE image in memory and then executing the image’s main entry point or an export function.
Among other activities, the image mapping process includes allocating memory for the image, storing the image headers and sections in the memory, populating the images’ import and delay import tables, adding exception handlers, and executing TLS callback and export routines. The Phant0m tool provides a complete implementation of this process.
While reflective image loading is a known technique at this time, its use was first observed in the DoublePulsar and subsequently the SlingShot frameworks in 2017 and 2018, respectively. This technique enables the fully fileless loading and execution of a malicious image without invoking the standard Windows API, such as LoadLibrary. This eliminates detection based on API hooking and file artifacts.
When it is finished executing, pc.exe displays a message indicating a version number and build timestamp: Version 2.2.1 - build on Jun 9 2022 16:02:12.
AddSecurityPackage64.dll
AddSecurityPackage64.dll, which is the original filename of this mim221 component, is responsible for:
Obtaining the SeDebugPrivilege and SYSTEM privilege by access token impersonation. This allows mim221 to inspect and extract credentials from the LSASS process.
Disabling Windows event logging in an attempt to evade detection; and
Injecting pc.dll into LSASS as a Security Package. Security Packages are used to extend the Windows authentication mechanism and can be abused to execute malicious code in the context of LSASS.
In an attempt to remain undetected, AddSecurityPackage64.dll disables Windows event logging by killing threads of the Windows Event Log service without stopping the execution of the service itself. This is achieved by locating the process that hosts the Event Log, enumerating the processes’ threads, identifying the threads assigned to the service by their service tag (eventlog), and terminating them.
Querying service tag information
AddSecurityPackage64.dll injects pc.dll into LSASS by deploying pc.dll as a Security Package. To this end, AddSecurityPackage64.dll issues an RPC call to LSASS – to the ncalrpc:[lsasspirpc] RPC endpoint, providing the file path to pc.dll to LSASS. This call instructs LSASS to load and execute pc.dll, which then stages the getHashFlsa64.dll credential theft component.
getHashFlsa64.dll conducts credential theft in the context of LSASS
pc.dll and getHashFlsa64.dll
In the context LSASS, pc.dll decrypts, reflectively loads, and executes the code credential theft component getHashFlsa64.dll in a manner similar to pc.exe. pc.dll and getHashFlsa64.dll share the same original filename: getHashFlsa64.dll.
pc.dll is implemented such that its main routine returns FALSE, making LSASS execute pc.dll and then unload it. This is a detection evasion technique making LSASS load pc.dll while avoiding appearing as an added (registered) Security Package. LSASS normally creates registry entries when adding Security Packages and does not unload them once loaded. This provides an opportunity for defenders to detect the loading of malicious Security Packages. Previous research provides more detail on this topic.
getHashFlsa64.dll accesses the memory of its host LSASS process and stores stolen credentials in a Mimikatz log file named pc.log for later exfiltration.
Example pc.log content
getHashFlsa64.dll exports a function named GetMyVersion, which displays a version number and build timestamp (Version 2.2.0 - build on May 28 2022 04:56:23), in a format consistent with the output from pc.exe. The credential theft functionality of getHashFlsa64.dll is implemented in its export function GetLogonInfo.
The GetMyVersion function
Additional Information
Error Messages and Public Code Reuse
The mim221 components implement error logging. The error messages follow a consistent output format.
Example error messages
It is important to note that we observed code segments that seem to be modified versions of publicly available code. For example, the implementation of AddSecurityPackage64.dll looks like an adaptation of public code that demonstrates injection of a Security Package into LSASS using RPC calls.
Similarity between publicly available code (top) and AddSecurityPackage64.dll (bottom)
Timestamp Information
The mim221 components that reflectively load other executables, pc.exe and pc.dll, patch beforehand a string in the loaded executable, which provides further timestamp information: [email protected]#0-2022-05-23 16:33:03S. The patching involves replacing the string with configuration information, such as the mim221 execution password and a path to the log file for storing stolen credentials.
Patched timestamp string
Attribution Analysis
We assess it is highly likely the initial attack phases we observed were conducted by Chinese threat actors with cyberespionage motivations. Telecommunication providers are frequent targets of espionage activity due to the sensitive data they hold. Our analysis identified indicators that point to the operation Soft Cell actors.
Operation Soft Cell has been associated with the Gallium group based on TTPs and some of the domains the group has been using.
Active since at least 2012, Gallium is likely a Chinese state-sponsored group that is targeting telecommunication, financial, and government entities in Southeast Asia, Europe, Africa, and the Middle East. While the group’s original focus has been on telecommunication providers, recent reports suggest that Gallium has recently expanded targeting across other sectors.
The initial intrusion vector and the majority of the TTPs we observed closely match those conducted by, or associated with, the Soft Cell actors. This includes deploying webshells at Microsoft Exchange servers for establishing an initial foothold, following same file naming conventions, using the LG tool and the net, query, and tasklist Windows built-in tools for gathering user and process information, and the PsExec Windows Sysinternals tool and net for lateral movement and exploration, respectively.
It is worth noting that the attackers’ activities at one of the targets suggested previous knowledge of the environment. We had observed activity at the same target a few months prior, which we attributed to Gallium primarily based on the use of the group’s PingPull backdoor and TTPs.
By pivoting on the original filename of mim221’s getHashFlsa64.dll, we observed another sample that steals credentials from LSASS. This sample has the PDB path of e:\vs_proj\mimkTools\getHashFlsa\getHashFlsa\x64\release\getHashFlsa64.pdb and has been first submitted to VirusTotal from Vietnam on January 04, 2023.
The path partially overlaps with the PDB path of a Mimikatz Soft Cell executable (E:\vs_proj\simplify_modify\Win32\simplify.pdb) and another Mimikatz executable of a Chinese threat actor thought to be part of the Soft Cell activity group arsenal (E:\vs_proj\mimkTools\dcsync_new\x64\dcsync64.pdb). This indicates that mim221 and these binaries may originate from the same source.
Closer analysis confirms that the sample we pivoted to is a previous, less-advanced version of mim221 – Version 2.2.0 – that does not include some mim221 components, such as AddSecurityPackage64.dll and pc.dll. We refer to this sample as mim220.
Output from mim220 (top) and mim221 (bottom)
Previous research indicates possible connections between the Soft Cell actors and APT41, which is known to conduct Chinese state-sponsored espionage activity as well as financially motivated activity targeting multiple sectors with a broad geographical coverage, including telecommunication providers.
The connection between the Soft Cell actors and APT41 that most relates to the activities that we observed is based on the Whizzimo, LLC certificate of the Soft Cell binary with a PDB path E:\vs_proj\simplify_modify\Win32\simplify.pdb, a binary that possibly originates from the same source as mim221. This certificate has been reported to be used by APT41. Pivoting on this certificate reveals further Mimikatz modifications, some with filenames very similar to those we observed.
Conclusions
Chinese cyberespionage threat actors are known to have a strategic interest in the Middle East. This is evident from their consistent targeted attacks on various entities including government, finance, entertainment, and telecommunication organizations. The recent activities targeting the telecommunication sector this post discusses are some of the latest such attacks.
Our analysis of mim221 highlights the continuous maintenance and further development of the Chinese espionage malware arsenal. These threat actors will almost certainly continue exploring and upgrading their tools with new techniques for evading detection, including integrating and modifying publicly available code.
SentinelLabs continues to monitor espionage activities and hopes that defenders will leverage the findings presented in this post to bolster their defenses.
In this post we will introduce you how to intercept and reverse the payload generated by the Nessus’s closed source plugins.
So we asked ourselves: is it possible to see what Nessus is doing under the hood?
Nessus is a proprietary tool developed by an American company named Tenable Inc, used for Vulnerability Assessment engagements by Cyber Security Companies. It can be used to scan single hosts or whole networks raising an alert if it discovers any vulnerabilities that can be abused to obtain access to the victim’s system. Nessus scans cover a wide range of technologies including operating systems, network devices, hypervisors, databases, web servers, and critical infrastructure.
The process of adding new security checks and release them into the general public domain is done by Tenable Inc. research staff. The Advanced Scan templates include an option that allows selecting which program has to be executed to find a specific vulnerability. Those programs, also known as plugins, are written using the Nessus Attack Scripting Language (NASL). Each plugin has some information about the vulnerability discovered: the impact that may have on an organization, the remediation, and, when is available, the Proof of Concept to verify the vulnerability.
During the last Red Team engagement, CYS4 has performed several manual and automatic testing activities. The automated part was done with the help of Nessus that has shown a potentially critical vulnerability (CVE-2017-12149) on a host:
JBoss RCE vulnerability identified by Nessus
At this point, many organizations would have stopped and reported to the client the finding identified by the automatic scanner without going into details of the issue, but in CYS4 we do things differently by trying harder ;)
From Nessus’s output, it was clear that it has successfully crafted a serialized object obtaining a custom error message from the victim but it was not able to leverage that vulnerability into a Remote Code Execution (RCE). In particular, DNS traffic was blocked by a firewall, so it was not possible to use a safer common payloads like URLDNS.
For this reason, we decided to reverse the plugin functionality, trying to understand how Nessus was able to trigger the custom error message.
At this stage we found three possible options:
Reverse the Nessus Script Language engine
Hook the engine functionalities
Perform a lazy MiTM attack to intercept the traffic.
We chose the third option, because it was more straightforward. In addition, some changes to NASL debugging module didn’t allow an easy instrumentation of the plugin module.
Setup
The first idea that came up to our minds to intercept the traffic, was using iptables to forward the Nessus traffic to the local HTTP proxy server (which, in our case, was Burp Suite). Because we had to run Nessus and the proxy in the same machine, we couldn’t use the PREROUTING table, as it only applies to packets coming from outside: a feasible workaround was to modify the destination port on packets OUTPUT sent by our Nessus process. The catch is that it could also have affected packets output by Burp Suite, getting into a routing loop. In order to solve this, it was necessary to capture only non-root traffic and run Nessus as an unprivileged user, as mentioned in this guide1.
According to the official Nessus documentation2, we had to follow these steps:
1. Install Nessus
2. Create a non-root account to run the Nessus service
#useradd -r nonprivuser
3. Remove ‘world’ permissions on Nessus binaries in the /sbin directory
#chmod 750 /opt/nessus/sbin/*
4. Change ownership of /opt/nessus to the non-root user.
… and we could finally run Nessus with the lowest privileges:
#systemctl daemon-reload
#service nessusd start
Exploitation
In our new set up environment, we finally succeeded in intercepting the Nessus request which could trigger the vulnerability. To reach our goal,we also decided to disable all the Nessus plugins and run a scan targeting the vulnerable host:
Request sent by Nessus to trigger RCE vulnerability
By analyzing the payload, it appeared like a serialized object which leveraged vulnerable CommonCollections libraries. So we were able to build a reverse shell payload using the ysoserial tool and the CommonCollections3 Java deserialization gadget:
After sending the malicious payload to the vulnerable server, we obtained Remote Code Execution (RCE) in the root user context using a reverse shell:
Request that could trigger RCE vulnerability sent using curl commandRequest received by local nc server
Conclusions
Simplifying the exploitation phase is crucial when time is limited. In this case, due to the time restrictions applied by the customer, intercepting the Nessus payload helped to successfully reduce the time spent in the exploitation phase for this target and allowed us to expand our attack surface.
Login
