A Little Wigle

Thanks to the proliferation of wardriving as a hobby, we now have a large database publicly available which allows us to search for signals in a given location. This database, known as Wigle, is user-friendly and community supported. Anyone can upload signal data - there's even an Android app. Now, we won't be providing an instructional section on using the platform. However, we would like to point out a couple of interesting features that can assist with your next wireless pentest, red team, or any other assessment involving signal data.

First up is the Only Nets I Was the First to See feature. This, as it says, allows you to search for networks that you discovered in a given area.

Now, this data is not aggregated by name since two unrelated individuals on two different sides of the world can call their network "FBI Surveillance Van". However, information for the same BSSID is aggregated. If a BSSID is captured and uploaded more than once over a period of time, this information is stored under the same ID, which allows you to view changes to a network over time. For example, you may be able to track certain BSSIDs changing from WPA to WPA2, or switching from supporting WPS to having WPS disabled. You can also track name changes.

The next feature is the advanced search. You can use this to search an area for networks supporting older encryption. For instance, if you're targeting a manufacturing facility that you suspect has older Wi-Fi equipment in use, why not leverage it for network access?

Some Pre-Reqs

There are several ways one could accrue data to upload to Wigle or collect for offline analysis, such as a wireless site survey (a crucial part of a good Wi-Fi pentest). As mentioned above, it's possible to use an Android app. Airodump-ng is written to support working with GPSD for this purpose as well. However, one of the most powerful tools for collecting signal and location data simultaneously is Kismet. Kismet has support for all sorts of signals, however we are going to focus on Wi-Fi, specifically the 6 GHz band.

We won't cover installing Kismet, GPS tools, or installing drivers for adapters for now. However, we'll provide an inventory list to get started:

• A laptop with virtualization software
• Alfa Networks AWUS036AXML & compatible 6 GHz tuned antennas
• A VNA if you did not purchase the antennas directly from Rokland or another legitimate Alfa reseller
• A USB GPS dongle
• Linux distribution with support for the mt7921au chipset, running in a VM. Kali is recommended at the current time of writing due to ease of use
• Kismet and dependencies

Once you have all of the necessary software installed, ensure your GPS dongle has downloaded it's almanac data and locked on to satellites. You can check this by running gpsmon -n and look for a message stating 3D Fix. It's suggested to keep the GPS dongle outdoors or near an open window to download almanac data, as it can take 20 minutes or more. When this has finished, you're ready to configure Kismet for picking up 6 GHz signals.

Configuring and Running Kismet

Getting ready to capture 6 GHz signals is fairly straightforward. You'll need to ensure that the 6 GHz band is available to your system, run sudo iw reg set US. Modify the primary config file: /etc/kismet/kismet.conf and add the following line source=wlan0:name=axe,band24ghz=false,band5ghz=false,band6ghz=true,channel=1w6e. Here's a breakdown of these parameters:

• source - The NIC you're using to capture signals.
• name - Whatever you would like to call the interface in Kismet.
• bandxghz - Configures the frequency band to operate on. We're excluding 2.4 and 5 GHz to target 6 GHz only.
• channel - This specifies channels the card will operate on. Each frequency band is divided into operating channels.

There are other parameters available if you would like to tune this further, just check out the Kismet documentation. Now that this is configured, let's run Kismet in Wardrive mode. Essentially, this mode saves power as it's monitoring for less information and outputs captured information to a format we can upload directly to Wigle. We'll do this with sudo kismet --override wardrive.

There we have it! Now you're ready to start wardriving on the 6 GHz band. If you elect not to use the --override wardrive option and only get a .kismet file, there's a built-in tool to transform this to a usable format for Wigle. Just run sudo kismetdb_to_wiglecsv --in xxx.kismet --out whatever.csv.

Next Up

The plan was to cover some defensive Wi-Fi tooling in this post, but we don't want you to fall asleep reading! So keep an eye out for our next post in the wireless series where we'll introduce Nzyme.

Wi-Fi 6E introduces the availability of the 6 GHz band, which spans 5925 - 7125 MHz (5.9 - 7.1 GHz). This turned tooling on its head. Not only would we need a new series of wireless NICs capable of monitor mode and packet injection, but many tools are set to check the 2.4 GHz band by default, with a flag for 5 GHz. Fortunately, as you'll see later on, developers had the forethought to allow specifying a frequency, or set of frequencies. In this post, we'll cover some tooling and take a look at how Wi-Fi 6E operates.

Alfa to the Rescue

As equipment started being available on the consumer market for Wi-Fi 6E, USB adapters supporting the standard were nonexistent. You had to use something with a built-in NIC supporting the standard. Netgear rushed to the finish to release the very first Wi-Fi 6E USB adapter: the Nighthawk AXE3000 (A8000). In my excitement, I pre-ordered it. I struggled for some time to get the mt7921au drivers to build on any system and eventually gave up as I had other priorities.

Then, Alfa stepped in. They released the AWUS036AXML alongside a specially tuned external antenna. I again pre-ordered this from Rokland and waited eagerly for its arrival. Since it has arrived, I've gotten familiar with using it in a variety of applications.

Setup

If you wish to follow along or build on my work here, you'll need the genuine Alfa adapter as well as antennas that are designed to handle Wi-Fi 6E. I recommend using the external antenna I mentioned earlier. With these in hand, you'll probably want to just use Kali and install the kali-tools-wireless meta-package to save yourself any grief.

To actually have the 6 GHz band available to your system, you'll need to run sudo iw reg set US. From here, to see all frequencies the adapter can scan, run iw phy.

Do not use iwlist frequency as this is deprecated and will not provide all channels.

The next step for working with a 6E network is identifying what frequency your target access point transmits on. With your adapter still in managed mode, run sudo iw dev wlan0 scan ap-force | grep -B 5 "SSID_NAME_HERE" and you'll see the frequency.

Now let's set the card to monitor mode and tune it to the specified frequency. We'll do this with the following commands:

• sudo ip link set wlan0 down
• sudo iw dev wlan0 set type monitor
• sudo iw wlan0 set freq 6375
• sudo ip link set wlan0 up

Then you can verify by running iwconfig.

Reading and Analyzing Packets

Now that our adapter is ready, we can capture some packets and actually perform analysis of packet structure if you would like. It's also important to ensure that you're using antennas that are properly tuned for the frequencies you'd like to work with, if you're not using the antennas that came with the card or the one shared above, you'll want to get a VNA (Vector Network Analyzer).

At this point, I realized that the frequency set is ignored by airodump. Run sudo airodump-ng wlan0 -C 6375 \--essid your-ap -w desired_filename to scan on the specified frequency, filter by essid, and write to several different files of various formats. It's also important that you're using antennas that are properly tuned for the frequencies you'd like to work with, if you're not using the antennas that came with the card or the one shared above, you'll want to get a VNA (Vector Network Analyzer). If you want to use every frequency available to the card, you can specify -C 0 instead. Once you have a .cap file, you can open it in Wireshark.

Opening the first "Broadcast" packet from the target device, we see a few interesting parameters. Since we're here, I'm going to analyze a couple of these parameters.

Robust Security Networks & Management Frame Protection

The first tag, "RSN Information" is not Wi-Fi 6E specific. This was actually introduced in WPA2 back in 2004. In this particular instance, there are two fields which are active.

The PTKSA (Pairwise Transient Key Association) replay counter assists in preventing, you guessed it, replay attacks. The next two fields are more recent and a highlight of WPA3. While these fields were present for some implementations of WPA2, this was an optional feature and required clients to support it. So what exactly is Management Frame Protection?

If you've ever performed any analysis on Wi-Fi traffic or performed a Wi-Fi pentest, you've probably seen management frames. Using airodump-ng, you can see clients associated to access points or probe requests from clients that are not associated to an access point. Additionally, most typical Wi-Fi pentests revolve around sending de-authentication or disassociation frames to force the four-way handshake to re-occur and capture it. These are all management frames. Management Frame Protection prevents these frames from being sent in cleartext - preventing reconnaissance or exploitation. WPA3 uses both MFPC and MFPR, however you may come across a WPA3 network where you can see associated clients. This occurs because of WPA3 Transition Mode. In this mode, clients that don't support WPA3 will connect using the WPA2 scheme.

The Wi-Fi 6/E High-Efficiency PHY

The High-Efficiency PHY supports higher data rates as it can support modulation up to 1024-QAM as opposed to 256-QAM in the previous generation of Wi-Fi. However the specific portion of the frame we're analyzing consists of PHY capabilities that handle timing, frame aggregation, and power consumption.

The first 3 parameters handle MAC Protocol Data Units (MPDUs) and Aggregate-MPDUs. Again, this all is to handle timing and frame aggregation. The last parameter, Spatial Multiplexing (SM) Power Save is a feature designed to help save power on devices that leverage Multi-Input/Multi-Output (MIMO), and in this case, has been disabled.

Coming Up Soon

In the next installment we'll cover wardriving, configuring Kismet to identify 6 GHz networks, and configuring the network defense tool Nzyme to monitor wireless networks.

Ahhh...Capture the Flag (CTF), and who doesn't like a formidable challenge? Security conferences are great and all, but it is always more fun to spend time with our team at STACKTITAN hacking on various CTF challenges. That is exactly what we recently did at Kernelcon 24.

The CTF ran through the con and was the typical jeopardy style with various categories and weighted challenges by difficulty. Solve the challenge, get the flag and post to the leaderboard. There was also a nice balance of challenges ranging from web application, mobile, hardware to reversing. The team was busy with presenting, so we didn't have a constant focus on the CTF but still ranked within the top 10. Not too bad.

The Android Challenge

Out of the many challenges, I tend to enjoy those about reversing and mobile applications. One such challenge, was The Terminator mobile application that said something to the likes of "Attack the terminator before your time runs out and the clock resets". It seemed interesting enough so here is the writeup about how I solved the challenge and beat the Governator.

The Terminator Android Application

First thing is to get a working environment to load the Android application (i.e., APK), so we load up Android Studio and the Virtual Device Manager. I am running a Pixel 6 Pro with API 30. When launching the image it will use Qemu as the emulator environment. Side note, not that it matters in this situation, but images with the Play Store enabled are non-rooted and images without the Play Store provide root access, which would look something like this:

Anyway, the APK is actually named GPTerminator.apk and can simply be dragged onto the running emulator's view, which will install it automagically (err...using ADB as the actual method). Viola...we get this.

After seeing the application and running it, we can see that it starts out with HP Remaining: 1984 and a Time Remaining: 15 seconds. So for every click of the ATTACK button, we decrement the HP Remaining counter. So yes, you will get tendonitis of the pointy finger before you can wear down the clock.

It should be pretty obvious that we either 1) make the time counter so high that we can click 1984 times (which sounds absolutely awful), or 2) we set the "HP Remaining count so low that we can click within the alloted time (yes much better).

Approaching the Solution

There are a couple of ways that we can solve this challenge. One would be to use an interposing/hooking solution, such as Frida, to hook the respective class method and return the desired result.

The other, and the technique I chose, was to decompile the APK, modify the code to do the needful, and then repackage. As an aside, had the application code been obfuscated using something like ProGuard, we would have opted for the Frida route considering we would have been looking at functional memory and not source code.

Decompiling the APK

There are quite a few utilities that decompile APKs, but most all of them are using apktool to perform the heavy lifting. Note, on a Mac, you can just perform a brew install apktool to get it onto the system.

Aside from the AndroidManifest.xml, which should always be reviewed for things like exported items, is the smali directories. So the deal with Smali is that it is really just an intermediary language that provides a human readable version of the compiled bytecode.  We can get back to Java source if we need to, but knowing how to read Smali is a valuable skill, in and of itself.

Analyzing the Source Code

Android applications typically leverage a reverse namespace convention such as com.example.gpterminator, which contains the application's primary functionality. With that, we have two directories of interest, smali and smali_classes2. The latter contains our namespace of interest and fortunately has very minimal functionality contained with the MainActivity.smali file.

Letting our eyes wash over the code, we can can see that there is a class constructor method (line 90) that returns void (i.e., .method public constructor ()V). There are also a couple of constants on lines 96 and 100. Imagine that, their hex to dec is 1984 and 15, which is the HP Remaining and Time Remaining values, respectively.

Ok so the logical thing to do is change 1984 to 1 (i.e., 0x1). I am not changing it to 0x0 because I need the satisfaction of at least one click of the ATTACK button!!!

As an aside, had the functionality been more complicated, I often use Frida to view the loaded classes, class methods and then watch anything that might be suspect or of interest. This helps to narrow in on the applicable source code when it comes time to trace the logic. Maybe more of this in a future blog post.

Recompiling the Code

The changes need to be recompiled which can also be done with apktool b <directory> -o modified.apk. At this point there might be a slight cleanup to AndroidManifest.xml due to a reference to an arbitrary non-existent debug resource, or similar. Easy enough to simply remove the troublesome statement from the Manifest and attempt to recompile again. I ran into this with the error: attribute android:dataExtractionRules not found.

Byte Aligning

After successfully recompiling the APK, we need to make sure the APK is byte aligned so that various uncompressed files are aligned relative to the start of the file image. Doing this is similar to any other alignment in that it makes memory management more performant.

To accomplish this, we use the zipalign utility provided within the Android Studio SDK (located within the build-tools directory). The command is zipalign -p 4 gpterm.apk gpterm-aligned.apk. Android Studio aligns to 4 bytes on both 32 and 64 bit archs, so we are directing zipalign to do the same here.

Code Signing the APK

Well we have made some modifications to the code and recompiled it, so it will need to be resigned in order to get it back onto an emulator or physical device. This is a two-step process 1) create a self-signed code signing certificate and 2) sign the APK.

Create the Code-Signing Certificate

To create the certificate pair, we use the keytool java utility. Use the following syntax:

keytool -genkey -v -keystore stackrelease.keystore -alias stackdroid-key -keyalg RSA -keysize 4096 -validity 10000

Sign the APK

Next, we will use the apksigner utility included as part of the Android Studio SDK. Use the following syntax:

apksigner sign --ks stackrelease.keystore --ks-key-alias stackdroid-key gpterm-aligned.apk

That's it. Now uninstall the old gpterminator.apk from the emulator and replace it with gpterm-aligned.apk. Launch and make sure it is functional.

Not Today, Arnold!

And now The Terminator isn't so tough! One click and no more SkyNet!!!! The lower right image provides the flag.

Conclusion

This was a fun exercise, and also demonstrates a technique that is useful when performing Android mobile security assessments. This is also my hope that it provides those that aren't too familiar with venturing into mobile penetration testing with the perspective that this discipline is completely accessible. Until next post, keep on hacking!

"Physical access is total access". This is what my instructor at the Marine Corps Communications and Electronics School told us as he demonstrated the password recovery procedure on a Cisco Catalyst 2960 switch. We had just completed most of the curriculum learning about networking concepts, configuring Cisco equipment, deploying Windows Server operating systems, and more to set up communications. At this point, he was driving home the importance of keeping equipment secure and out of the hands of an adversary. For the uninitiated, gaining access to certain models of Cisco switches and routers without credentials is merely a means of power cycling the device, holding the mode button, and issuing a few commands.

Fast forward a few years and I'm on my first engagement attempting to access a secure, multi-tenant facility completely on my own with minimal training. I perform a few basic checks; how many entrances/exits are there? Is anything aside from the lobby unlocked? Of the 3 or 4 doors on the outside of the building, none were unlocked aside from the lobby entrance. This was also early 2021 so there were a total of 3 vehicles in the parking lot, no opportunity to tailgate. That ended up being the end of my ideas and the end of the assessment. I walked away feeling like I hadn't given the client any value.

Now I've completed the Practical Physical Exploitation course and can say without a doubt I'm ready and equipped to breach some facilities. This course really has everything you need with no fluff.

Course Structure and Pre-Reqs

The Practical Physical Exploitation course, taught by Travis Weathers of Optiv and Ralph May of Black Hills Information Security, is exactly as advertised. Practical. As such, everything is set to mimic an efficiently run, real-world engagement. They spend very little time on theory and lots on hands-on learning. The course is 3 days long, with the first containing the most instruction and the last being the course capstone. Here's a quick breakdown:

• Day 1 - Introductions, in-class instruction, PEAK, recon
• Day 2 - Recon pt. 2, Practical arts and crafts, night ops
• Day 3 - More recon, CAPEX, after action report

There are a few things you will need to have for the course to ensure you get the full hands-on experience.

• A laptop where you can run proxmark either in a VM or natively
• A vehicle that can fit at least two other people and some equipment
• Some kind of mobile hot-spot. Whether this is directly off your phone or a puck, is up to you

It's All Business

The first day contains the most presentations. After this, very little time is spent looking at slides. One of the key aspects the instructors focus on during day 1 is the business side of engagements:

• Scoping and selling
• Acquiring appropriate authorization
• Client communication
• Reporting

Though not a foreign topic for most pentesters, red teamers, or other security professionals, Physical Penetration assessments have a unique perspective. If you're struggling to sell these assessments, or just getting started, this section of the course makes all the difference.

After you're done discussing the business aspects of engagements, you learn about practical remote recon. What's out there, publicly available, about a business? There are some key points in this section that are the foundation of your success now and for the rest of your career as a physical pentester. From here, you're introduced to PPE's PEAK equipment. After you're briefed on these tools of the trade, you begin your first real-world exercise.

Course Handouts

Aside from the practical skills and lessons learned, one of the things you walk away from this course with is a handful of document templates:

• Scoping questionnaire
• Statement of Work
• Kick-off call notes
• Authorization Letter & questionnaire
• Report template
• Badge templates

You also get access to PPE's student portal, where you'll be able to review all course material.

Physical Exploitation and Access Kit (PEAK)

As part of this course, your team, or if you're like my small class of 3, each individual, will receive a PEAK during day 1 (to be returned at the end of the course). This is the Physical Exploitation and Access Kit. It contains everything you need to conduct an engagement with the exception of a computer and smart phone. If you've looked at one of these kits before, the variant provided is the full kit that contains the surveillance and stealth equipment. By far my favorite piece of equipment was the Nikon P900 with it's long range zoom lens.

If you're staying in a hotel or somewhere else with ADA compliant door handles, I highly recommend practicing with the under door tool. For those interested, they do sell these kits here.

Quick tips for success

While the instructors give you everything you need to succeed, there are a few things you can do to make everything go smoother:

• Pay attention to the little details
• Memorize the differences in badge readers
• Elect a team captain. The team captain should divide work among the team and keep track of objectives, client communications, and who has what gear during an op. This will help ensure no overlap occurs without missing anything.

With this hefty introduction completed, let's move on to what this is all about, what you do in the class.

Day 1

As mentioned previously, day 1 is where you'll look at slides the most. Once you've been briefed on the business aspect of physical security engagements, the fun starts. The rest of day 1 is mostly hands on with debriefing after practical exercises.

Remote Reconnaissance

Your first exercise is performing remote reconnaissance against a fictitious company. In this stage, you'll want to gather as much information about the target from online sources. Primary areas you're concerned with are the building and employee online presence.

When searching for an address online, there are tons of resources that will provide additional information about a commercial space. It's a good idea to use multiple sources here, especially when looking at street views of buildings. Speaking of street view, this is your first opportunity to get eyes on cameras.

Employee presence comes to general social media intelligence, or SOCMINT, practices. What you're looking for here is names, roles, and have they posted their badge online somewhere. Real world tip here: people, especially new hires, love posting their badges on Instagram and TikTok.

On-Site Reconnaissance

Walking through the next phase of the engagement, you're tasked with performing some on-site reconnaissance. At this phase, you're increasing operational risk. Everything you do from here could burn the op. You need to keep a low profile.

There are two primary types of on-site recon: mobile and close-proximity. Given the risky nature of on-site recon, close-proximity should be used only as a last resort. This is where you would walk the premises and gather necessary information. Our team did not do this, however the instructors did some close-proximity recon and shared results during the debrief.

During mobile recon, you're again faced with two choices: dynamic or static. With dynamic mobile recon, you're continuously on the move. Drive around the campus at a slow, but reasonable speed to capture video and/or images. Depart and review, and if needed, return after an extended cool-down period. Regarding static mobile recon, it's exactly what it sounds like. Park the vehicle and take your video and images from that position, being careful not to attract attention.

Making Ralphs

After you've debriefed the third exercise, it's time for some arts and crafts. You'll get hands-on practice with making badges. This is done with a blank badge, silhouette paper, packing tape, a hole punch, and patience. You'll probably mess up a few times, but Ralph has plenty pictures to spare.

After you've made your Ralphs and perfected the art of badge-making, you'll be briefed on some additional intel the team has gathered. The team will be informed that [REDACTED] employees often visit a local [REDACTED] before heading to work. They've been spotted with their badges visible. Once you've been provided the location, I recommend going with your team to plan out the next morning's operation.

Day 2

This is the longest day of the course, however, it's arguably the most fun. You start off the morning trying not to look suspicious at the breakfast location. Your team should be set up to capture video and images to get a clear reference image of the [REDACTED] employee badge. Then you'll need to modify the template to match this image, save it to a thumb drive, and print on silhouette paper at FedEx. You'll take this back to class and be briefed on some additional intel that was gathered. [REDACTED] employees have been identified regularly going to [REDACTED] for lunch. This is your chance to pull data from the badges to clone them.

Badge Cloning

As I've noted above, you'll want to make sure you paid attention to what type of badge readers the organization has deployed when performing your recon. This will determine what kind of reader you'll need to carry for cloning. Carry the wrong reader, and you won't get any data. You'll be briefly introduced to operating the readers, web interface, and proxmark in the classroom prior to departing. Once you're comfortable, it's time to head to the lunch location.

Everyone has their own approach to getting badge reads, whether it be navigating a tight space, using team members to herd, or going through a line to get somewhere. Directly approaching someone to ask for directions is perfectly valid as well, just be aware of the size of the target organization. In a real engagement, you need to consider the likelihood that you could compromise the operation taking this approach. However you decide to tackle this challenge, you need at least two badge reads to ensure you have adequate data - "Two is one and one is none".

With your newly acquired badge data, it'll be time to return to class, and make a working badge for [REDACTED]. The instructors have a test reader set up so that you can verify you've done this correctly, and you'll be given a chance to compare your badge with the "real" badge for [REDACTED].

Once everyone has had a chance to test and compare badges, you're done with this first fictitious company. It's time to review some methodology, and be briefed on your final target.

Final Target, Night Ops, Bonus Points

During this brief, you'll receive paperwork to sign and review as you are now targeting a real company, under a fictitious name for purposes of the course. You'll receive the scope and objectives, and go through a mock-up of normal engagement procedures starting with a kick-off call. The instructors will then disclose the location of the facility and provide you with similar intel to the practice target about a common breakfast stop for employees. You're given a buffer window before on-site reconnaissance is authorized. During this time I recommend traveling to the breakfast location, performing remote recon on the target, and formulating a plan for next steps.

Once you've acquired adequate information, it's time to perform on-site reconnaissance. At this point, you may have realized it's helpful to have more than one vehicle at your disposal. Our team performed two rounds of dynamic mobile reconnaissance approximately 20 minutes apart. From there, one team member dropped myself and another team member at an off-site location where we walked to perform close-proximity mobile recon. If you take this route, this is your first chance to achieve a bonus objective and garner additional information to complete your remote recon. Just make sure you communicate with the "client" that you're preparing to do this.

Day 3

The last day of the course consists of the CAPEX and debrief. This is where you will use everything you've learned up to this point to perform a facility breach and achieve any bonus objectives that are still left.

Lessons Learned

Have you noticed how I've mentioned having the correct badge reader, taking note of the technologies in use, and paying attention to little details several times so far? At the breakfast location for the CAPEX target, our team was equipped with the wrong readers. However, some adaptability went a long way and we got the necessary reads to clone badges for the target company.

Once inside, I split off to tackle a bonus objective while the other two targeted the primary objective. This took longer than expected and we were getting frustrated with our designated tasks, so we switched. This is what led to our success. If you're struggling, let someone else take the reins.

Final Thoughts

The Practical Physical Exploitation course is well worth the time, money, and effort. The instructors have built an excellent offering that is a true "zero to hero" style course that not only new pentesters, but seasoned professionals would both gain value from attending. Beyond the skills gained, you also get a certificate of completion and some gear. Specifically, you receive a REX gun, nozzle adapters, nozzles, a Doppelgänger breakout board, and some stickers.

And We Left Off Here...

If you haven't read Part 1 of this series, then please do so and head back over here. For those that just want to jump in, the TLDR is that we bought a commodity APC surge protector and made it into a hollow shell that could house a Raspberry PI and LTE equipment. The most important aspect of the build was that the APC supports ethernet, so we rewired it as the LAN interface for our covert hardware implant (i.e., the APC).

In doing all of this, and nearly burning up our Dremel, we had a few remaining items to accomplish in order to get the Covert Hardware Implant (CHI) operational. In this post we will configure the Raspberry Pi to support the following:

1. Command and control communication that supports tool delivery and data exfiltration through out-of-band channels.
2. The enterprise logical footprint should be as minimal/non-existent as possible.

With that, we'll need to get the Raspberry Pi operational before applying any configurations or scripts.

Raspberry Pi Initial Operating System Install

First, we need to install the operating system, so navigate over to the official Raspberry Pi website and download the Raspberry Pi Imager software.

Note: The operating system is read from a MicroSD card, the same one as described in our first blog post of this series. So grab the MicroSD card, and make sure that the computer running the Raspberry Pi Imager utility is capable of writing to an SD card.

Once the Imager is running on your operating system, we are using OSX, then select Raspberry Pi 4 and the Raspberry Pi OS (64-bit) along with the storage device location of the SD card, which should mount and display within the /dev (*Nix) or /Volumes (OSX) directory.

One thing that we don't want to contend with is connecting a keyboard and monitor to our Raspberry Pi just to configure the device. Fortunately, the Imager has a very useful feature which allows for adding configuration build settings. Specifically, we can provide a pre-configuration build setting that configures WiFi networking, which will be used to automatically connect to our local wireless network. The second item is configuring SSH key auth so that we can authenticate to the Raspberry Pi over the wireless network. To access these configurations you will click NEXT and EDIT SETTINGS.

Once the writing has finished, put the SD Card back into the Pi and power it on. You should now see the PI, along with an IP, on the wireless network. Ensure that that it is accessible via SSH key auth, such as ssh -i private_key username@pi_destination.

Transport Considerations

We explored several options when building out our infrastructure for handling device callbacks. Three methods of establishing reliable communication channels come to mind - SSH, OpenVPN, and Wireguard.

Using SSH, you can initialize an outbound connection from your hardware implant to a publicly-facing endpoint and specify a remote port forward. A typical command string would contain -R <desired listening port>:localhost:22 and would result in <desired listening port> on the public endpoint presenting the hardware implant's SSH authentication interface. This solution is simple, but adds additional headaches when trying to dynamically forward traffic back through the hardware implant.

OpenVPN and Wireguard provide a more robust VPN solution. The PKI aspect of OpenVPN can be cumbersome to manage, and processing overhead can increase latency, which lead us to using Wireguard.

The Wireguard Setup

You'll want a publicly accessible endpoint to host your Wireguard server on. We deployed a small EC2 instance and configured a security group to allow inbound traffic on UDP 51820 (Wireguard's default listening port). For increased operational security, we're going to configure Squid on this server so that we can proxy traffic from the hardware implant to install tooling and more. Install the necessary utilities:

apt install -y wireguard wireguard-tools squid

Additionally, enable IPv4 forwarding and ensure it persists after reboot:

echo 1 > /proc/sys/net/ipv4/ip_forward

Edit /etc/sysctl.conf (reference line 16):

# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1

Now, we'll set up Wireguard on the server side. Generate a new private key:

# wg genkey
gLzEJxpUBdAuas9ZRWR6lnJkteaTgFAIPOnFcXk5MUA=

Provide the generated private key and other details in /etc/wireguard/wg0.conf. We're going to use the network range of 10.2.0.0/24 for client and server networking.

[Interface]
Address = 10.2.0.1/24
ListenPort = 51820
PrivateKey = gLzEJxpUBdAuas9ZRWR6lnJkteaTgFAIPOnFcXk5MUA=

Start the Wireguard server with systemctl wg-quick@wg0. Verify that the service is up with the wg command:

# wg
interface: wg0
  public key: cpO6ZAy4se4871WpWlsLjavryUqjqWBBf2xvxG6Eihc=
  private key: (hidden)
  listening port: 51820

We'll revisit the wg0.conf file once the client is set up. Let's get Squid configured to allow traffic from 'local' networks. Edit /etc/squid/squid.conf and update lines 1408 and 1409:

Restart Squid with systemctl restart squid.service.

On the hardware device, generate a private key (wg genkey) and create /etc/wireguard/wg0.conf with the following details:

[Interface]
Address = 10.2.0.2/24
# Output from 'wg genkey'
PrivateKey = cNzQvNKUe6eoNLhyX0YPmxi/xAx4UUIAQvZO2XWKLFg=

[Peer]
# This is the public address and port of your vpn endpoint
Endpoint = xxx.xxx.xxx.xxx:51820 
# And the public key 
PublicKey = cpO6ZAy4se4871WpWlsLjavryUqjqWBBf2xvxG6Eihc=
PersistentKeepalive = 30
AllowedIPs = 10.2.0.0/24

Let's grab the  public key for the hardware device's configuration:

# echo 'cNzQvNKUe6eoNLhyX0YPmxi/xAx4UUIAQvZO2XWKLFg=' | wg pubkey
1civ0MWfnrzF3crQQ6/LXT1yqIV1DpP08yubTuq1X2A=

Now we can update the server's configuration, so that the hardware device is allowed to connect. Add the following [Peer] section to /etc/wireguard/wg0.conf:

[Peer]
PublicKey = 1civ0MWfnrzF3crQQ6/LXT1yqIV1DpP08yubTuq1X2A=
AllowedIPs = 10.2.0.2/32

Restart wireguard on both client and server with systemctl restart wg-quick@wg0. Further, make sure the service is enabled at boot with systemctl enable wg-quick@wg0, and status of the connections can be checked with wg.

To take advantage of the proxy that we put in place, you can export the http_proxy and https_proxy variables in your shell to direct most tools to send traffic to Squid.

export http_proxy='http://10.2.0.1:3128'
export https_proxy='http://10.2.0.1:3128'

Tool installation via apt through the proxy can be achieved by creating a file located at /etc/apt/apt.conf.d/proxy.conf with the following contents:

Acquire {
  HTTP::proxy "http://10.2.0.1:3128/";
  HTTPS::proxy "http://10.2.0.1:3128/";
}

Software Goals

To recap, our goal is to deploy a resilient and silent (from a client's internal network standpoint) method of remote access. Any and all communication to our remote VPN endpoint should take place over the cellular network, NOT over the ethernet connection.

We're going to employ NetworkManager, as it's the default utility for managing network connections in PI OS. Originally, we had developed a set of service files and management scripts to handle initializing the connection and ensuring graceful recovery in the event of a failure. However, while putting together this blog post, we realized NetworkManager works perfectly well handling the connection status. Don't worry, nobody is bitter about the time spent learning hardware-specific AT commands and living inside minicom for a week.

Anyhow, the LTE modem needs to be in a certain configuration mode, so we need to install minicom for further changes:

# apt install -y minicom

Let's connect to the LTE modem and set the USB mode to '4' (ECM mode).

# minicom -D /dev/ttyUSB2 -b 115200
AT
OK
AT#USBCFG=4
OK

If you receive an error, check status with AT#USBCFG? - which should return '4'. You may also see other output in the minicom terminal, likely from commands ran by networkmanager to check the signal strength and device status.

Disconnect with CTRL-a x <enter>. We can now create a new connection using nmcli and set the APN for Twilio (remember the SIM card from Part 1), and verify connectivity with ping.

nmcli connection add con-name Twilio type gsm ifname ttyUSB2 apn wireless.twilio.com

We need to set a static route so that VPN-related traffic is explicitly sent over the LTE connection. To do that, we'll modify the new connection and specify our VPN endpoint as follows (we'll use 8.8.8.8 as our pretend VPN endpoint):

nmcli c modify cd0965fa-b93d-4c02-add4-441acda9b8b2 +ipv4.routes 8.8.8.8/32

Bring the connection down and back up to verify changes:

Comparing ping times shows that traffic sent to our 'VPN endpoint' is traversing the cellular connection, as the latency is significantly higher.

One of the issues we ran in to during testing was configuring SSH to listen on the Wireguard interface's address only. Systemd would try and start the SSH service before the Wireguard interface was up, and resulted in the service failing to start and essentially locking us out of the device. Edit /etc/systemd/system/sshd.service, adding the service and device referenced on lines 4 and 5 below:

[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service wg-quick@wg0.service
Requires=sys-devices-virtual-net-wg0.device
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

Now we can configure SSH to listen on the Wireguard IP. Uncomment line 17 and replace 0.0.0.0 with the Wireguard interface's address.

root@hotpacket:~# cat /etc/ssh/sshd_config

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/usr/bin:/bin:/usr/games

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

At this point, if all went well, the raspberry Pi should be functional and accessible via the LTE cellular network. Once confirmed, the APC surge protector housing can be screwed back together and is ready to be used in your next Red Team engagement.

Conclusion

Hopefully this was interesting and if you followed along, and possibly even built one of these, we want to hear from you. Always looking for methods to improve upon the build to include form-factor and additional features. The STACKTITAN team is working on the next version of the surge protector, and hopeful (time permitting) that it will be complete prior to release at upcoming security conferences. Keep on building and hacking!

Why Another Hardware Implant?

Many hardware implants have already been created by hobbyists and commercial companies, alike. We are no different in that regard. However, we use our hardware implants in real-world Red Team operations while constantly evolving the form factor to align with the most effective solution for the mission. These are battle-tested and proven to work. Lessons are learned and changes are applied, as necessary. We thought it might be interesting to some that may be looking to up their field-kit, might not get an opportunity to perform uninhibited breaches of organizations, or simply enjoy learning by practical application.

What we aim to achieve in the next couple of blog posts is to help describe our solution, detail the bill-of-materials, exemplify the build process, and finally live-fire our covert hardware implant (CHI).  

The Guiding Criteria for the Build

Ok let's get this out of the way. If you are building and placing a covert implant in an environment that looks like a computer development board (i.e., raspberry pi, Panda, etc.) then expect it to be observed as suspect. Things that look suspect get detected, and things that look less suspicious often times get overlooked. Which leads to the first criteria:

The physical form-factor must be unassuming and must blend into the surrounding environment.

The implant is going to be placed in a hostile environment where detection instrumentation is going to possibly and most likely inspect traffic. This means that relying on command and control (C2) over a traditional corporate enterprise network isn't the best solution. The second criteria:

Command and control communications that supports tool delivery and data exfiltration through out-of-band channels.

In a similar vein, the operational traffic, that which will explore and compromise enterprise systems will be seperate from the C2 communication channel (i.e., traverse a separate network interface on the implant). This comes with a number of other considerations. The most notable would be assuring that enterprise tooling that often proactively scan assets (e.g., vulnerability detection, asset inventory, excessive privilege, etc.) are rendered blind to our device.

The enterprise logical footprint should be as minimal/non-existent as possible.

Finally, the implant should be relatively free of complexity and should be serviceable with minimal effort.

The implant should be able to support easily acquirable commodity hardware so that operators can perform field expedient repairs, as necessary.

Hardware Bill of Materials (BOM)

1. APC Surge Protector (P11VNT3)

A surge protector is an obvious choice that would work in most any corporate environment. Whether it is actually in use or not, nobody is going to question the presence of this form factor. We also set out to find one that supported wired Ethernet ports, as this is going to provide LAN side enterprise connectivity.

After a bit of searching through the endless Amazons, we came upon the APC P11VNT3 model, which seemed to have all the preliminary bones necessary to support our build. The price point was also well within reason at around $40 USD.

2. Raspberry Pi 4 Model B

Either the Pi 3 or Pi 4 should work just fine. The supply and demand seems to have calmed down a bit, and can be located relatively close to MSRP (Buy at Sparkfun) . We are looking to reengineer the solution to use more readily available prototyping boards, but for now this is the proven adaptation.  

3. Cellular LTE Components

SIXFAB Pi 4 LTE Hat - This will act as the bridge between the Raspberry Pi and the Telit LTE modem.

SIXFAB LTE Antenna - This is the u.FL connected antenna that supports both LTE and GNSS.

Telit LE910C4 Mini PCIe LTE CAT4 Module -  The module serves as the actual LTE modem that will be attached to the SIXFAB LTE Base Hat.

Twilio SIM Card Service - Twilio has partnered with T-Mobile (US) to provide a general pay-as-you-go SIM service for IOT solutions.

4. Miscellaneous Connectors, Cables and Storage

MicroSD Card - Recommend using an SD card with a descent amount of storage and IO speeds. We chose to use both Lexar and Sandisk Ultra 128GB cards, which have met our field requirements.

USB Cable (1 FT USB-C to USB-C) - The inside of the surge protector is rather limited in space, so choose a 6 inch to 1 foot USB-C cable. One end should be a straight connector and the other should be a 90 degree connector.

Leviton Power Cord Plug - The surge protector's power cord will be terminated to this device. We chose to use the original APC power cord due to the cord fitting that secures the cord with the APC case.

Anker USB-C Block Charger - A block charger will provide power to the Raspberry Pi and it's inherent LTE components.

Adhesive Backed 1/16" Silicon Rubber Sheet - The silicone sheeting will be cut to adhere to the internal bottom side of the APC case. It is a tight fight, so the combination of the rubber anti-slip surface and snug fit of the closed case will prevent the internals from sliding around.

Brass Spacer Standoff Kit - This is just a general purpose kit to make it easier to fit the LTE hat onto the Raspberry Pi 4.

Dismantling and Clearancing

The first thing we want to do is dismantle the housing in order to see what we're dealing with, so that we can start to piece together our new internal components. Note that this particular APC uses security screws, so you will want to use a "spanner" screwdriver to decouple the back from the front pans.

At this point you can snip all the wires as we will only reuse the power cord. The large PCB in the lower left nearest to the power cord can be removed, along with all of the copper conductors, which are providing power to each power outlet.

The next task is to get dirty using a Dremel rotary cutoff tool.  Disregard the power cable and the USB adapter plugged into it, that is something we will add later. For now, the Dremel should be used to cut away and smooth down all of the excess plastic, similar to the following image.

The bottom of the tray will also need the Dremel treatment. The idea is to spend some time really removing as much of the plastic material as possible and smoothing out the pan, but make sure not to remove the stantions (yellow arrows) that are used to secure the lower pan to the upper pan.

Optional (Strongly Recommend): Cut a piece of the adhesive backed rubber and fit it to the bottom of the pan. This will help to secure and prevent the Raspberry Pi from sliding around within the APC case.

Networking and Communications

The advantage of this particular APC is the onboard ethernet surge protection. This is also the module that will need to be rewired to support Ethernet for our intended purposes. First order is to locate the module that looks like the following (right-most image) and pull it from the APC housing. There is a small tab that holds it secure, so take your time and gently remove the component.

Once removed, you will want to use either a soldering iron or a hot-air rework gun to desolder and remove all of the diodes as shown in the highlighted box below. The finished product should resemble something similar to the left-most image below.

Flipping the Ethernet PCB component over to expose the traces, we can observe the "in" port and the respective pinout. Although it is easy enough to follow the traces on the PCB, the pins and there respective destination solder points are clearly labeled below to remove any confusion.

This is the point where soldering skills will come into play. We recommend using a 22 AWG solid core tinned copper hook-up wire (2-3 inches long) along with a bit of flux at the solder point to make wiring the ethernet connection to the PCB a bit less painful. Then grab an ethernet cable and cut it down to a 6 inch section with the RJ45 plug still intact, and strip the sheathing back about 1 inch.

The next task is to wire the ethernet connection to the solid core hook-up wires. The following diagram is for a 568B Ethernet wiring spec, but this is simply soldering pins 1,2,3 and 6 to their respective PCB solid-core hook-up wires.

The final product should look similar to the following picture. Also not the gratuitous use of heat-wrap, both for the individual wire connections and the ethernet cable overall. Don't use electrical tape, it is a mess and doesn't instill confidence that your connections are protected adequately.

Wiring the Power Cord

The power cord has a special fitting that holds it securely in the APC case. Unfortunately, it has to be reused and it is a P.I.T.A to repurpose. Specifically, cut the power cord right below the 90 degree fitting. Then strip about 6 inches of sheathing from the cable.

Now you will need to muscle the cut wires out of the 90 degree fitting. It will give way but it does require force to remove the wires. I had to Dremel the inside of the 90 degree fitting so that I could rework the 6 inches or so of wire back through the fitting. This will also take some finesse because it is a tight fit. Once complete, you should have a final product that is indistinguishable from the OEM power cord.

The reason why we had to go through the trouble of reworking the power cord, is because cutting the wiring from the various PCBs during disassembly didn't leave much room to terminate the power, neutral and ground wires to our Leviton plug end. As you can observe in the following picture, we now have even lengths and secure connections.

The following is an illustration of the placement along with the Leviton plug end fitted back into the APC case.

Assembling the Raspberry Pi

This will be a quick step-by-step of the assembly to demonstrate how all of the components fit together. Most readers that are familiar with the Raspberry Pi format should already find it intuitive.

The following is a list of components clockwise from upper-left to include the 128GB MicroSD card, the USB connection cable, the Raspberry Pi 4, the Telik mini-PCI LTE modem connected to the Pulse LTE antenna, and the Sixfab LTE base hat.

Initially, we want to start with the Raspberry Pi 4 and install the Sixfab LTE base hat using brass spacers and screws from the Brass Spacer Standoff Kit. Once secured, it should look like the following.  

Note that the use of a header extension will be required, although it should have been included with the Sixfab LTE base hat kit. The following image illustrates the fitment when installed correctly.

Now we are ready to install the actual Telik LTE modem. Connect the u.FL connectors from the Pulse LTE antenna to the Telik board. Ensure the GPS/GNSS and LTE connectors are attached in the correct order. Then simply snap the Telik board into the mini-PCI slot of the Sixfab LTE base hat.

If using the Twilio wireless service, then you will have received a SIM card. This is what we use at STACKTITAN, and it has worked flawlessly with stable daily access running over months-long operations. Install the SIM as follows.  

The final task, is to connect the USB cable from the Raspberry Pi's USB-3 port to the micro-USB connection on the Sixfab LTE base hat. The following depicts a completed build ready for placement into the APC.

Final Hardware Assembly of the APC

All of our hard work has paid off and now comes the time to piece it all together. One suggestion is to cut a couple of adhesive backed rubber strips and place them as depicted by the yellow arrows in the following image. This will help to secure the Raspberry Pi and keep it from sliding within the APC. Also, placing a couple of 3M adhesive pads as depicted by the blue arrows will provide a solid surface to adhere the LTE antenna.

Assemble everything into the upper pan of the APC as shown below. Number 1 depicts the Anker block charger and the USB-C cable (straight-end) connections. Number 2 is the location for the ethernet cable connection. Finally, number 3 is the location for the opposing end of USB-C cable (90 degree) mated to the USB-C port on the Raspberry Pi. Make sure to adhere the Pulse LTE antenna, as well.

Now fit the bottom pan to the upper pan and flip the entire APC over. Don't worry about securing the pans together with screws. This is just a test fitment to ensure clearances are adequate. If everything fits, you just successfully assembled your APC covert hardware implant. Flip it back over and remove the bottom pan, so that we can access the Raspberry Pi.  

Next Steps...Part 2: CHI OS and Scripting

All of this may have seemed like quite a bit of work to get to this point. Agreed, it does take some time. We have built multiple CHIs; although, the effort is worth it as the CHI performs well in the field. This leads us to the next reason for building such devices.

Remember that Red Team customers are unique in the fact that they often have extended the necessary effort to build out their security programs (people, technology, and processes). A "traditional penetration test" simply is not adequate for such clients, as they want a solution that evolves and grows along with their detection and prevention capabilities. As such, they demand creativity, realistic threat emulations and skilled tradecraft necessary to assess risk from multiple perspectives. If you are an organization that is interested in this style of testing, reach out to STACKTITAN as we would welcome the opportunity to create a custom engagement and talk tradecraft.

We hope this has provided some inspiration for building hardware implants. In the next series of this post, we are going to install the operating system, create scripts to make everything work and finally verify that our CHI is operational.

Preface

This was an interesting journey into what I thought was going to entail lifting data from a typical SPI or I2C chip, but alas it was neither, rather the Microwire protocol. Let's explore this protocol, how we might interface with a Microwire EEPROM and extract data using the newly released Arduino UNO R4 eval board. I mean...this was really just some weekend hacking and a chance to crack open this shiny new Arduino...right?!

Test Environment

The board that we are targeting is a proprietary commercial USB programmer that is used to interface with Texas Instrument MSP430 microcontrollers, and specifically as a means to access SPY-BI-WIRE (SBW). Although, SBW is not the intent of this post but is something that will be a future post as it is an interesting method to multiplex JTAG over a two-wire protocol.

The other important part is selecting the correct GPIO interface for extracting data from the USB programmer's IC. I am just going to say that I started to reach for the Bus Pirate, then I thought about the GreatFet, but realized that I had an Arduino UNO R4 that is a perfectly capable ESP32 enabled eval board. This decision to use the latter actually turned into an ideal exercise to explore the Arduino IDE, write some C, and simply do some experimentation. This is what we are dealing with (Arduino lower side of picture and USB programmer near the top)...

Inspecting the USB Programmer

Looking at this device, we can see some interesting items. First, even though this was originally enclosed in a plastic case, is that the manufacturer/designer has not done anything to obfuscate the various interfaces. This is to be expected as it is a programmer and used to interface with target device GPIO, itself. The other obvious items are the M-Cortex and JTAG interfaces on the far right.

Why not just hook up a JTAGulator and bit bang the pins? Well, if we trace the VIAs (i.e., the copper substrate lines) through the PCB, we run into a bank of resistors. The resistors are shielding the components (i.e., MCU and EEPROM) from voltages on the target device. As such, the M-Cortex ( i.e., 10 pin JTAG) and the 14 pin JTAG are simply there as two options to interface with equivalent GPIO on the target device. It is unlikely that the JTAG interface will provide uninhibited access to the on-board component-chain as we might expect.

Alternatively, the EEPROM uses a Micro Small Outline Package with exposed legs and the pitch is perfect for a Pomona SOIC 5250 test clip.

Inspecting the EEPROM's Data Sheet

The labeling on this EEPROM was a bit hard to read, so until our stereo microscope arrives, let's just say that it is a Microchip 93LC46B package. The respective data-sheet appears as follows:

Now most everyone has likely been introduced to the SPI or I2C protocols used in serial communications, but this is neither. Instead, this EEPROM uses Microwire. So what is Microwire?

Microwire

Microwire can be thought of as the predecessor to SPI. Whereas SPI utilizes a 4-wire circuit (i.e., MISO - master in slave out, MOSI - master out slave in, CLK/SCK - serial clock, CS/SS - chip select), Microwire uses a 3-wire circuit (i.e., MISO, MOSI, and CLK/SCK). Microwire permits variable length, but is dependent on the type of package and uses the ORG pin configuration to determine memory management (e.g., word size). The other notable item is that Microwire is slightly slower than SPI. Lastly, is that Microwire does not "float" the CS voltage (i.e., neither high nor low), meaning that the voltage is explicitly tied high or low to determine whether or not the chip is actively listening or not.

More about the 93LC46B EEPROM

This particular EEPROM does not support the ORG pin, meaning that the memory Word Size is a fixed 16bit width. Additionally, we might want to know the address bus width, in other words, the number of addresses we have available.  

The data sheet states: 64 x 16-bit Organization 'B' Devices (no ORG)

If we have a fixed word size of 16bits and the memory layout is 64 rows, then we can do some quick math to get the address bus width of 6 bits. This will be useful later on.

log2(64) = 6 // 2x2x2x2x2x2 = 64

Wiring the Arduino UNO R4 and EEPROM

The Arduino UNO series of boards have numerous prototyping capabilities and the latest ESP32 enabled R4 is much the same layout, but more powerful. The wiring should align with the following table, whereas an Arduino UNO and EEPROM schematic are provided for reference. The finished wiring will look similar to the first picture of this post.

The Arduino IDE and the MicrowireEEPROM lib

I started down the path of reading the data sheet and coding Microwire functionality, but then came upon a couple of usable Microwire Arduino libraries. I don't want to take away from the importance of creating or building from the ground up, but already having an understanding of how the underlying protocol works makes using someone else's research a convenience.

MicrowireEEPROM

microWire

I read through the code for the MicrowireEEPROM and decided that it would be enough to build a usable Arduino Sketch. However, I want to dig into a couple of MicrowireEEPROM.cpp functions as they will help to understand the code we will write, shortly.

As we want to read the memory of the EEPROM, there are two primary functions, the MicrowireEEPROM::read() and the MicrowireEEPROM::send_opcode(). Note that the read() function requires information about the address width and the page size that we determined early on. As a result, we are going to cycle through all of the 64 memory addresses and read 16 bits of data from each.

Now, notice that the read() function calls "send_opcode(2)" and passes "2" as it's parameter. Reference the Instruction Set for the 93XX46B package. Notice that the READ instruction has a binary opcode of "10" which is a decimal "2". Also, note how Microwire explicitly controls the state of chip select (CS) when writing and reading, which I had alluded to earlier.

Again, nothing really novel here, but my hope is that this instills an appreciation for the data sheets and how much information is afforded within their pages. They are a wealth of knowledge and extremely useful when reconciling your understanding alongside code.  

Writing the Sketch

Finally, we want to leverage the Arduino-IDE to create our code that will be used to read out the data of the EEPROM. The MicrowireEEPROM library has an example sketch called EEPROMTest.ino, which we will use as our foundation. I am going to fast-forward to our code and walk through the functionality.

First, we setup the Arduino UNO pins and map them to their respective functions on line 6. On line 12, we set the address page size and the address bus width, again those are both values we determined earlier on. The other value is serial clock speed which is set to a default 200 microseconds.

#include <MicrowireEEPROM.h>

// Microwire needs four wires (apart from VCC/GND) DO,DI,CS,CLK
// configure them here, note that DO and DI are the pins of the
// EEPROM, so DI is an output of the uC, while DO is an input
int CSEL=13; int CLK=12; int DI=7; int DO=2;

// EEPROMS have different sizes. Also the number of bits per page varies.
// We need to configure the page size in bits (PGS) and address bus width
// in bits (ADW). The speed at which the clock is run is configured in
// microseconds.
int PGS=16; int ADW=6; int SPD=200;

// initialize the library
MicrowireEEPROM ME(CSEL, CLK, DI, DO, PGS, ADW, SPD); 

void setup() {
  Serial.begin(9600);
}

void loop() {
  for (int addr=0; addr < (1<<ADW); addr++) {
    
    // read the value
    uint16_t readValue = ME.read(addr);
    
    // give some debug output
    Serial.print("Address "); 
    Serial.println(addr, HEX);

    Serial.print("Read ");
    unsigned char high_byte = readValue >> 8;
    unsigned char low_byte = readValue & 0xFF;
    char h[7];
    char l[7];

    sprintf(h, "%02x", high_byte);
    Serial.print(h);

    sprintf(l, "%02x", low_byte);
    Serial.print(l);
    Serial.println();
    
    delay(1000);
  }  
}

The setup() function is simply to set the serial baud rate to a reasonable value of 9600. The loop() function is performing a bit-shift operation at line 22, which is walking through all of the possible addresses (i.e., 64 total). Line 25, we are using a unsigned 16 bit integer data type to store the data located at a specific memory address.

Lines 32 - 42 require some slight voodoo, which is essentially breaking apart our 16 bit stored value into a lower and upper 8 bit values, respectively. We are doing this so we can "0-pad" string format each byte and then present the lower and upper values as two cleanly formatted bytes. The following screenshot of Arduino-IDE's Serial Monitor illustrates the output produced by our code.

Conclusion

Obviously, there is more that can be done with the data output at this point, which will likely come about as part of a future post. For now, we set out to extract data from this Microwire EEPROM, which we accomplished. It may not be the most elegant solution, but this is hacking and sometimes we just need "it" to work. Having an arsenal of tools at our disposal, including the Arduino UNO R4, is essential to accomplishing our objective. Sure, we could have accomplished the same task with another eval board, but exploring often leads to new discoveries and keeps things interesting. With that, we hope you found this interesting and keep on the lookout for future hardware hacking posts. More on the way!

Introduction

After receiving multiple phone calls from what our caller ID reported as the rich and famous only to find out it was our own Alex Sanders on the other end, he is here to demonstrate the process associated with the tech and process used to do so.

When it comes to social engineering, voice phishing can make or break the engagement. A lot of people are trained to deal with suspicious emails and documents, very few have meaningful training on suspicious calls. In this article we’re going to walk through the process of setting up self-hosted tooling to perform these calls.

Before getting started, it’s important that you, the social engineer, think about what your ruse or pretext, along with the desired premise and outcome. Does your ruse require you to spoof a phone number? Do you only need the area code to originate from a location aligned with the target person or organization? If you want to save on costs and can get away with just a matching area code, a service like TextNow would suffice. Download the app, sign up with any email, deny location permissions, enter the area code you’re matching, and choose a number.

If you need to spoof the entire phone number, you essentially have two options: services like SpoofCard or your own Private Branch Exchange (PBX). Spoofcard works well enough, but if you want to have reliable control over your services and an understanding of what’s happening behind the scenes, you should stand up your own PBX. So what is a PBX? To answer that, we need to understand a little about Voice over IP (VoIP), in general.

VoIP Overview

Back, many years prior to the EV revolution of current day, phone calls were placed over somewhat "closed" networks and protocols. This network, similar to how we think of the Internet, was referred to as the Public Switched Telephone Network (PSTN). How did someone or something (e.g., analog modem) interface with the PSTN. Via Earthlink or America Online, of course! Albeit, there is some truth in that, the PSTN was accessed through PBXes that resided within a Central Office (CO). A CO was literally a collection of necessary equipment, which contained the PBX, switches, and all the rest of the goods housed within a large building in all major cities.

As you can probably ascertain, this was costly to maintain and copper "land lines" were geographically limited as compared to our modern expectations of liberated communications. With that, just as we put radio on the Internet, we did so with voice phone calls, as well.  

VoIP is a protocol stack that permits placing phone calls over Internet (i.e., IP) based medium. VoIP can communicate directly and natively over IP with other VoIP devices, and interact with phone exchanges via the PSTN. The latter, use of the PSTN, is typically still a fundamental necessity when dialing by phone-number, for example. Additionally, VoIP devices and analog telephony devices can coexist through Analog-to-Digital | Digital-to-Analog converters (i.e. ATA). All of this interaction still leverages a PBX as the gatekeeper, of sorts.

Typical VoIP communication is comprised of two parts, 1. SIP (Session Initiation Protocol) and 2. RTP (Real Time Protocol). SIP establishes and manages the connection (i.e., call setup and teardown) while RTP delivers the payload (e.g., audio signals). The architecture for the infrastructure involved typically goes as follows – a DID (Direct Inward Dialing) number is registered via a SIP trunk provider, the technician then configures a phone to register to a PBX (Private Branch Exchange) server and dial out through this DID number at the provider. So what is the SIP Provider, you might ask? There is still a requirement to be able to access the PSTN, as we described earlier, and the SIP Provider maintains their own litany of PBX devices that knows how to interface with the telecommunication conglomerate's closed PSTN. Anyway, enough of the history lesson, let's get our hands dirty with some tech...

Preparing the PBX and Choosing a SIP Provider

Now that we’ve had an overview on how these systems work in theory, let’s set up our self-hosted PBX. You’ll want to download a copy of Debian 11 and install the following packages: wget tar vim jq.

From here, ensure your terminal window is fullscreen, or the next script will fail to set up asterisk. Use wget to download the IncrediblePBX2027-D.sh script that does most of the heavy lifting for us. Make sure to apply execute permissions, chmod +x <script>, to the script and then run it as root. This will set up all the necessary packages and configure them to play nicely, as well as create several additional scripts in the root home directory for management of the server.

Once this has finished, run the admin-pw-change and apache-pw-change scripts from the root home directory. At this point, we’ll need to register with Skyetel (i.e., the SIP Provider) and purchase a DID phone number. Once this is done, configure an IP Group to allow communication to their servers. This can be done manually, but we’ve used another script to automate this. Execute the script and follow the prompts.

Configure the PBX and Soft-Phone Handset

Now that our public IP is allowed to communicate with Skyetel’s servers, we need to manage our PBX and phone system. There are four (4) main components we need to concern ourselves with:

• Extensions – internal identification of phones
• IP addressing
• SIP Trunks – what servers our VoIP traffic communicates with and how to communicate with them
• Outbound Routes – which trunks are in use, and Dial Patterns – how the PBX parses dialed numbers

For all changes in Incredible PBX, you must use the Submit button on the bottom right and apply changes using the red Apply Config button in the top right. First we’ll navigate to Settings > Advanced SIP Settings and use the Detect Network Settings button to auto-populate our LAN and WAN details.

Next we’ll create a SIP extension so that a local endpoint (e.g., SIP enabled phone handset) can communicate with the PBX using traditional SIP over TCP 5060 (note that TLS enabled SIP is typically TCP 5061). These extensions are unique to each endpoint, such as each employee often has their own desk phone and number.

Navigate to Applications > Extensions, click the Add Extensions drop down, and select +Add New SIP (Legacy0 [chan_sip] Extension. Fill out the User Extension, Display Name, and Secret fields. A secret here should be treated similar to a password. It needs to be composed with enough length and complexity to prevent compromise of the extension. As an aside, this sort of attack is often referred to as registration hijacking, and we wrote some code a while back as a proof-of-concept, if interested in exploring further.

With an extension configured, we need to set up an actual phone. We had mentioned desk phones, but many organizations have moved to software based phones (soft-phones). Soft-phones are arguably more feature rich, and many are integrated into operating systems or cloud subscriptions, already. If not, numerous open-source soft-phones are available, which provide everything necessary to gey up and running.  With that said, we are going to configure the Zoiper soft-phone. Jumping right in, the username field should be the extension you configured @ the hostname or IP of the PBX instance. The password field will be the secret you configured for the extension, hostname will be the hostname or IP of the PBX.

As long as this doesn’t fail to register, we’ll move on to configuring the outbound route for the PBX to communicate with Skyetel. Otherwise, if you’ve chosen another provider, you will need to configure trunks and a dial plan for that provider as Incredible PBX 2027 is already set up to work with Skyetel.

Navigate to Connectivity > Outbound Routes > Add Outbound Route. Fill in the values for Route Name and Route CID (this is the phone number you’ve purchased through Skyetel). The Trunk Sequence for Matched Routes will be the trunks that are pre-configured for Skyetel.

Next we’ll navigate to the Dial Patterns tab and use the Dial patterns wizards button to make sure our calls will complete as dialed. De-select the EU Emergency option, and leave the other default selections in place. Click the Generate Routes button, then submit and apply the config.

With all of this configured, we can place a call from Zoiper to verify that everything works as intended. Once we have a regular call working, we can fill in the Outbound CID under the Extensions configuration with the number we intend to spoof and test that. Voila, here I am making a call to myself as the local casino...which has informed me that I have already lost at Texas hold-em! Better luck in Vegas.

Conclusion

We hope that you found this useful and has inspired you to explore VoIP technologies. Although, voice phishing may not be everyone’s favorite social engineering vector, it can be effective with the right tools and planning. With a little additional configuration, this could even be used as part of a regular email phishing campaign: supply a phone number for users to call at the bottom of the email to verify the legitimacy of an email, get in touch with support over an invoice, or whatever ruse you can come up with. Have fun, spoof responsibly, and until next time.

This post is going to cover one of many processes to lift firmware from an Integrated Circuit (IC) chip. There are many methods that can be used such as interfacing with General Purpose Input/Output (GPIO) interfaces (e.g., UART, JTAG, etc.). However, when confronted with the opportunity to extract firmware directly from an IC, the process can be rather uncomplicated as we will demonstrate. Don't worry, we will be demonstrating other techniques necessary to extract firmware in upcoming posts.

Test Environment

Our sacrificial board is from a D-Link (i.e., D-Link DIR-817LW) donor device, which can be considered a residential class 802.11x wireless router.

We will use a Pomona Electronics 5250 SOIC test clip to provide direct access to the IC chip. Quality test clips, such as the Pomona brand, can be rather expensive compared to cheaper alternatives, but their dependability justifies the cost when others fail to align to tight IC tolerances.

Lastly, we will use the infamous Bus Pirate as the FTDI interface necessary to communicate with the IC chip's protocol, which is typically either I2C or SPI.

The following photo depicts our lab setup, but we can't make any of the connections until confirming IC chip manufacturer, protocol, pinouts, etc. So let's discuss next...

Inspecting the IC Chip

Circuit boards are usually architected with their components situated around quadrants. For example, ethernet components and chips may reside or may rather be compartmentalized in one section of the board, wireless radios and their components in another, and so on. This board follows that same design pattern, whereas the center of the board has what appears to be a multiprocessor package, a Dimm package and an IC. The IC is of interest as it supports non-volatile memory storage, which is perfect for a firmware location.

Inspecting the IC chip, we can see that it is a WinBond W25Q128FV. The reason for obtaining this information should be obvious, but if not, this will allow for further technical referencing via the manufacturer's data-sheet.

Considering the WinBond chip is commodity hardware used in many boards, Digi-key or similar has publicly available data-sheets, which can be located here. Reading the first few pages of the data-sheet provides information that our IC chip is of type Serial Peripheral Interface (SPI) with an operating tolerance between 2.7V and 3.6V. This is enough information to move to the next phase, which consists of wiring the test equipment.

Wiring the Components

Again, referencing the WinBond data-sheet, we can find the pinout for the IC SPI chip. The naming conventions within the data-sheet and the pinout provided on the Bus Pirate are somewhat different, so we have created the following table to make the mapping easier.

Note the circle on the upper left will indicate the top of the chip. This will also coincide with the indented or raised circle found on the actual physical chip, as to provide a common reference point when wiring for the pinout.

A word of caution when wiring the Bus Pirate. Although DangerousPrototypes created the original Bus Pirate, various versions have been released since then. For example, Seeed Studio and Sparkfun each have their own version, and each have different colored wiring schemes, so take note of your version and wire accordingly.

Once wired, the Pomona SOIC test clip should look similar to that depicted within the image below. Again from a top-down view of the test clip, the upper-left should have CS and the lower-right should end with MOSI.

Finishing Up

This section is provided to dispel one common question that I believe confuses most when getting into hardware, and that is to power on the board or not to power on the board.

Keep in mind that we are dealing with, and directly accessing, a single IC chip, which we can supply VCC (our own voltage supply). Further, the Bus Pirate can supply 3v3 power, which is well within the operating tolerances of the IC chip. Therefore, there is no need for us to power on the entire board when we can simply supply our own to the single component of interest. Further, providing power to only the IC chip, and not the board as a whole, prevents possible conflicts when reading from the chip as it will refrain from communicating I/O with surrounding peripherals/packages. Providing isolated power to the IC chip is the preferred method here.

However, a reason for powering the entire board may be when dealing with voltages outside of our Bus Pirate's tolerances, or using another method of lifting firmware, such as tying an MPU RESET pin to GROUND in order to introduce an I/O idle or hold state. Again, we will cover this in another post, but this is hacking so it is always good to have options.

With that, make the connection by securing the Pomona SOIC test clip so that the CS pin matches that of the IC chip (recall the circle indent). It should look similar to the following.

Lifting the Firmware

If you stuck with us this far, we have finally arrived! It is time to extract the firmware from this IC chip. To get started we need to make sure that we have a system running the flashrom program. Flashrom supports a myriad of test devices, protocols and chip manufacturers, thus reducing the heavy lifting associated with flash memory manipulation.

In the following we are telling flashrom to use the Bus Pirate and SPI protocol (i.e., buspirate_spi) and passing it the device location (e.g., /dev/ttyUSB0). The dmesg command can be helpful in locating the device when operating from a Linux system. If successful, the WinBond chip should have been found.

stack_lab$ sudo flashrom -p buspirate_spi:dev=/dev/ttyUSB0
flashrom v1.2 on Linux 5.4.0-136-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Bus Pirate firmware 6.1 and older does not support SPI speeds above 2 MHz. Limiting speed to 2 MHz.
It is recommended to upgrade to firmware 6.2 or newer.
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on buspirate_spi.
No operations were specified.

The next step is similar to prior, however, this time we want to define the speed in which the memory I/O reads are performed. The speed ranges from 30k to 8M, and there is a tradeoff. The lower the read rate, the more accurate the results but at a cost of an extremely lengthy duration. Contrarily, the faster the read the less accurate the results. Providing a speed of 1M is typically a good compromise for both speed and accuracy, albeit still time to make a pot of coffee...slam it..and make another! The -c option simply declares the type of chip and the -r is the name of the file to be created that will contain the firmware.

stack_lab$ sudo flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -c W25Q128.V -r W25Q128.V.bin
flashrom v1.2 on Linux 5.4.0-136-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on buspirate_spi.
Reading flash... done.

Running this after some time should have produced our firmware file, so we might assume success. Trust but verify.

stack_lab$ ls -alh W25Q128.V.bin 
-rw-r--r-- 1 root root 16M Jan 28 15:08 W25Q128.V.bin

Just to confirm, we can use the glorious binwalk utility to help parse the firmware file for known data types. The -M options simply tells binwalk to recurse during analysis. As we can see, the file is in fact a firmware that also contains a squashfs file-system. With that, you are left to your own devices to hack on!

stack_lab$ binwalk -M ext_firmware.bin 

Scan Time:     2023-02-12 14:03:26
Target File:   W25Q128.V.bin
MD5 Checksum:  b35279b4d39d377f47187ac847f43567
Signatures:    411

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
7104          0x1BC0          LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 75376 bytes
196660        0x30034         bzip2 compressed data, block size = 900k
524288        0x80000         TRX firmware header, little endian, image size: 5722112 bytes, CRC32: 0x365EA7FA, flags: 0x0, version: 1, header size: 28 bytes, loader offset: 0x1C, linux kernel offset: 0x1A2D80, rootfs offset: 0x0
524316        0x8001C         LZMA compressed data, properties: 0x5D, dictionary size: 65536 bytes, uncompressed size: 4225056 bytes
917504        0xE0000         SEAMA firmware header, big endian, meta size: 36, image size: 7622688
917536        0xE0020         Unix path: /dev/mtdblock/6
917568        0xE0040         LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 4970636 bytes
2490432       0x260040        PackImg section delimiter tag, little endian size: 5266432 bytes; big endian size: 6049792 bytes
2490464       0x260060        Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 6049169 bytes, 2246 inodes, blocksize: 131072 bytes, created: 2014-03-06 09:37:02

Conclusion

We have demonstrated the tools required to lift firmware using a Pomona SOIC test clip, the Bus Pirate, and a few open-source tools. This was in contrast to accessing firmware using common techniques, such as interfacing with UART or JTAG. It is important to understand many methods and techniques when performing hardware hacking, as these technologies and board configurations can always be a challenge. We hope that this post may assist aspiring hardware hackers out there, and provide a common reference for others. Stay tuned, the STACKTITAN team will be posting on more hardware topics very soon.

Picking Back Up

In the previous post of this series, we looked at smbexec.py from the Impacket library and how it works under the hood. This was done by using Procmon to observe what happens on a system when smbexec.py connects to it and executes commands. We also made some observations about ways a defender could build detections based on the nature of smbexec.py.

We had to disable Microsoft Defender to perform this exercise, as it was detecting and blocking our activities. Today we are turning Defender back on, validating some of those guesses on how Defender detects smbexec.py, and then bypassing those detections. Afterwards, we are going to repeat the process to accomplish the same results on a popular EDR product.

Reviewing What We Know

The first logical place to start is by changing some of the static details about smbexec.py, such as the Service Name, filenames, and paths. You can find most of the static elements of the script on the lines below.

These are the default values in the latest version of Impacket’s smbexec.py (as of today in February 2023). You will notice some of the values we saw during the last blog post -- “BTOBTO” was the service name created via a registry write, and “execute.bat” and “__output” are the temporary files for executing commands and writing their output. The “SMBSERVER_DIR” and “DUMMY_SHARE” are only leveraged during the “server mode” of smbexec.py, which we are not covering in this series.

Kicking the Defender Tires

Starting with changing the “SERVICE_NAME”, we re-ran smbexec.py and were met with the same Defender detection and alert.

Meanwhile, this was how things looked from the attacking box… not a very revealing error.

Making changes to the “BATCH_FILENAME” and “OUTPUT_FILENAME” variables also didn’t have any effect on Defender’s detection and alerting. However, there are some additional static elements throughout the script, as seen below:

Here we can see the full file paths being built for the output and batch files. We changed the batch file path to another which is often world-writeable, \Users\Public\Downloads, and reran smbexec.py:

OK — that worked! We already bypassed detection and alerting from Defender, by only changing four static values. There were still multiple other potential detection vectors that we hadn’t touched yet, so this was surprising.

At this point, we went back and grabbed a fresh copy of smbexec.py and changed only the batch file path, to see if that was the only necessary change.

As we can see, it was! By changing only the path to the batch file, we had completely bypassed Defender. We should mention this is Defender in its default state with only Cloud Submission disabled. Defender was up to date on definitions and associated Windows Updates. With this in mind, let’s pivot over to testing against a certain commercial EDR product. Surely the same approach won’t work there… :)

Kicking the EDR Tires...A Bit Harder

The EDR product was installed on a separate workstation, with Defender in a disabled state. This was to avoid any conflicts or overlaps in detection. The EDR product was fully enabled and in “block” mode, and it was up to date on the latest definitions.

The first thing we tested here was the same smbexec.py with only the batch file path changed. However, this was detected and blocked...bummer.

We then tinkered with the same attributes that were changed during the Defender testing (despite it not being necessary for bypassing Defender), such as paths and filenames, but to no avail— still caught.

In thinking about when the script gets caught, we noticed that it happens immediately, before even typing a first command. This means we need to look at what is happening during initialization, before the first command execution.

In examining the “RemoteShell” class, we see numerous tasks happening within “init”. Most of it seems pretty self-explanatory, and again we can ignore anything related to SERVER mode. Towards the bottom before other functions are defined (line 209 for us) we see this self.do_cd(‘’) take place.

What does this do? Let’s find out.

Ahh, right. If you’ve run smbexec.py before and tried to CD to a directory, you’ve seen this error— “You can’t CD under SMBEXEC”. This is because, as we know from our previous blog posts, smbexec.py isn’t a real interactive shell. Every command that we run results in a new execution of our Windows Service and command shell, with a new batch file, and a new output file. In the bottom half of the above screenshot, we see this “execute_remote(‘cd ‘), where the output is gathered, newline characters stripped, and a “>” added to the end. This is our fake command “prompt” that is written out, imitating Windows Command Prompt’s prompt:

That thing. And it seems smbexec.py generates this prompt text before every single command that we run. You may have already gathered that from the previous blog post. This is the “echo cd” that we observed being executed (and detected) on an endpoint. Here it is again:

If this static one-liner is executed every time we run smbexec.py, regardless of what commands we run… that’s a pretty good IOC, wouldn’t you say?

Let’s get rid of it. We don’t care about our current working path anyway, because we can’t change  directory.

Let's rerun our custom.py with this change, and see what happens...

This is progress! We now get to command execution before things are blocked. After the previous change, we now know EDR is looking at our full command line. We’ve changed almost everything except our command shell. Let’s change it.

One of our favorite methods of doing…well anything, is Living-Off-the-Land. What better way to fly under the radar than to abuse the tools that are already installed on a target?

Head over to the LOLBAS project (https://lolbas-project.github.io/) and pick out a binary that allows for execution. Then just pop it into your smbexec.py shell, and try again! NOTE: Pay attention to the command line usage. Each of these binaries is different, with different command line usage. Might need to tweak things to get it to work for your use case.

We chose conhost.exe at random, and plugged it into my smbexec.py. To our delight, some things ran successfully! We are getting ever so close.

You will see above, however, that while running an “echo” worked, running “whoami” did not. We’ve still got a little work to do to get all commands working. Let’s try throwing PowerShell into our command execution chain (line 278 for us):

The eagle has landed! So by changing our full execution chain for running “whoami” from “cmd.exe -> whoami” to “conhost.exe -> cmd.exe -> powershell.exe -> whoami” we have fully bypassed detection by a certain EDR product!

Conclusion

Yes, this was a very “dirty” and unscientific approach to EDR bypassing. Yes, the resulting code is pretty convoluted… it could use some extra comments after what we’ve done. But— it works. And not just the specific LOLBAS binary that we chose at random. Even if everyone who reads this blogpost uses conhost.exe and gets it “burned” / added to EDR static signatures— it’s still just a single LOLBAS. Switch to another, and carry on hacking! We can even completely change up our command line. We still have “cmd.exe /Q /c” in our execution chain, which really isn’t necessary. Maybe conhost -> powershell is all we need to bypass. Maybe we even do some additional obfuscation, such as encoding things, etc. We have lots of options at this point.

This wraps up our series on SMBExec.py from Impacket. Thanks for reading along, and hopefully this has helped you dive deeper into how the tool works, how different endpoint security products detect it, and how we can bypass those detections.

Overview

SMBExec.py is a powerful tool in a pentester’s arsenal. It has been analyzed and blogged about countless times. However, in my experience these posts are mostly from the standpoint of the defender— what Event Logs are generated, what static IOCs exist, etc. This post will take a different approach, examining SMBExec.py from the standpoint of an attacker looking to gain a deeper understanding of their tooling. This will then enable us in future posts to look at ways that defenders detect this tool, and later to modify the tool to evade those detections.

How Does it Work?

There are a few different ways to go about examining this particular tool. While it is open source, and therefore we could just read through the code, we wanted to demonstrate analyzing the tool from a blackbox standpoint. Additionally, it is often beneficial to visually inspect and trace the actions taken by the binary during runtime. As such, we primarily leveraged Process Monitor (“procmon”) for this purpose, running it on the target Windows 10 device, while firing off smbexec.py against it from a Linux VM. Procmon recorded the actions taken, allowing us to further sort and filter to view the results we were interested in. Let’s take a look.

First off, Windows Defender had to be disabled on the target host. It’s a bit of a spoiler, but in the screenshot below you can see what payload it is concerned with.

And over on the Linux VM side, the following error was received when the tool was blocked by Defender. The error isn’t very intuitive, so we figured this was worth sharing.

After disabling Defender and re-running smbexec.py, we were able to record the associated actions with Procmon. You can see the list of actions pertaining to starting the connection and authenticating below.

A TCP connection is initiated from the Linux VM to the “microsoft-ds” service (which is SMB on TCP port 445), followed by some TCP sends and receives. The authentication process begins, with some LSA-related registry keys being queried and local account look-up being performed. As this is a domain account, local account look-up fails, and the host queries the Domain Controller instead. After successfully authenticating, more traffic takes place with the Linux VM over SMB, and finally we get into the functionality unique to smbexec.py.

A new Windows Service is created with the name “BTOBTO”, and we can see some registry key values being set. One notable key value “ImagePath”, holds a command line one-liner.

The “%COMSPEC%” variable is the full system path to cmd.exe. We can see that this command will create an “execute.bat” in %TEMP% which will run “cd” and write its output to the local default C$ SMB share, execute it, and then delete it. This is how smbexec.py creates the text in the prompt that is displayed when it is awaiting commands (ex: “C:\Windows\System32>”). Walking through the list of actions, we can see that all of this takes place. Cmd.exe is run, creating execute.bat.

Execute.bat is run, it runs “cd”, and writes its output to the “__output” file on the local C$ share.

A number of TCP sends and receives occur across the SMB connection, presumably sending the results from the “__output” file, and then execute.bat is deleted. This file delete activity was hard to find within Procmon, as it was not listed as a FileDelete operation or anything else aptly named. Instead, under a CreateFile operation you can see a “Delete on Close” option being set, followed by a CloseFile operation. This seems to be the deletion of execute.bat that is referenced in the command one-liner. If you need to search for this in Procmon, you can leverage the “CTRL+F” search feature to search for “Delete on”.

Finally, the BTOBTO Service is deleted.

This entire process chain happens as a result of the “cd” command that is run to generate the text prompt within the smbexec.py window. Luckily, the process of executing a command is nearly identical, where the command-to-be-run is echo’d into execute.bat rather than the “cd” command. Below is an example of the “whoami” command being run via smbexec.py.

As you can see, the “BTOBTO” Service name is reused, as well as the “execute.bat” file name. Furthermore, the “echo cd” command occurs in between every command run by a user via smbexec.py.

Execution Flow

After all of the above, the following general execution flow can be described for smbexec.py:

1. TCP connection via SMB from attacker to target
2. Authentication (Local first, falling back to domain auth if local fails)
3. Execution of the “cd” command
   a. Creation of BTOBTO service
   b. Execution of BTOBTO service
    i. Echoing command to %TEMP%\execute.bat
    ii. Executing execute.bat
    iii. Deleting execute.bat
   c. Deletion of BTOBTO service
4. Execution of command entered by user
   a. Same process as 3.a – 3.c
5. Execution of the “cd” command
   a. Identical to step 3
6. Execution of next command entered by user

The pattern then continues for as long as a user continues to enter commands for smbexec.py. These steps now make a lot of sense, for anyone that has ever experienced smbexec.py terminating prematurely, and then being unable to run smbexec.py again— the process chain must have terminated before execute.bat or BTOBTO was able to be deleted. As the code reuses these names over and over, conflicts with those filenames are very possible.

Detection

This should also give us plenty to think about from a Detection standpoint. Let’s look at some basic, static Indicators of Compromise (IOC) that we can list out from what we have observed.

• The Service name created on a target endpoint is always “BTOBTO”
• The path “%TEMP%\execute.bat” is always created on the target endpoint’s filesystem
 • The actual unwrapped path may change, where the path pointed to by %TEMP% differs. In our case, it was C:\Windows\Temp
• In between running user-provided commands via smbexec.py in its default mode of operation, the tool always executes a command beginning with the following:
 • %COMSPEC% /Q /c echo cd^> \127.0.0.1\C$__output 2^>&1 [snip]
   • Again, %COMSPEC% will unroll to the full path to cmd.exe. For the vast majority of all systems, this will point to C:\Windows\System32\cmd.exe
• The C:__output file for retrieving command output always has this same name, and is at the same location (when smbexec.py is run with default options)

Conclusion

That’s a good place to start for understanding how smbexec.py works behind the scenes, and creating some basic detection via static IOCs. In the next post in this series we will go over bypassing endpoint security controls’ detection and blocking of smbexec.py.

Following the completion of all our penetration tests and assessments we take time to review the findings and the deliverable with our customers. During this review, we almost always get asked the following:

Of all the vulnerabilities you identified, which ones would you mitigate first? We're a small team and need to know where our time is best spent.

This is the reality of security... While all organizations want to achieve "perfect" security, the truth is that (for most companies) limiting factors such as budget, human resources, and business needs decrease the likelihood of ever achieving that goal.

So, we did an exercise. We held a working session with all the STACKTITAN security consultants to determine three recommendations we'd make to all customers. These recommendations, subjectively identified from our experience performing thousands of assessments over a 15 year timespan, meet the following requirements:

• Requires no additional (or very minimal) spend on product
• Can be implemented by most organizations using current, internal staff
• Requires minimal time and effort to perform
• Achieves a remarkable improvement on security posture
• Addresses an issue or bad practice that is very common

So, with those requirements in mind, here's what we came up with over a pot of coffee and some heated brainstorming. By the way, we aren't discounting the importance of a comprehensive security program. We believe the most effective operating environment is one that relies on defense-in-depth. We simply tried to identify a few impactful actions that aren't extraordinarily expensive.

1. Perimeter Attack Surface Reduction

TLDR: Reducing the attack surface with stringent access controls is a cost-effective method of protecting against external, Internet-based threat actors.

The What:
Reduce the publicly accessible services, systems, and applications. That is, update access controls (e.g., firewall, web server) to limit the available attack surface to only the minimal resources necessary for the business.

The Why:
Look, we can pick a handful of vulnerabilities we commonly identify on our customer's Internet-facing systems. Oftentimes, these issues are identified in superfluous services or application functionality. Further, some of these services are attractive targets for attackers (e.g., web management portals, Windows services such as RDP and SMB, etc.). While we will always advocate for patching and hardening your systems and software, it can be a difficult and costly practice that requires continual management, updated inventory, etc. Restricting access to or decommissioning these services can be a cheaper alternative that reduces the likelihood of a breach. It's not the perfect solution and may just kick the can down the road, but it's an effective method to controlling your risk exposure from the hostile Internet.

The How:
We recommend, amongst other practices, the following:

• Implement a Default-Deny firewall access control policy
• Review firewall rulesets to identify overly promiscuous or unnecessary rules. After identifying any that are too broad, fix 'em.
• Review your perimeter web applications. Use tools like nmap, aquatone, and gobuster to quickly survey the landscape. Whatchu got out there and is there a reason for it to be there? If not, 86 it!
• Hunt for common management portals (e.g., devices, Java Web Application such as Tomcat, etc.). They're common targets. Restrict access to them. This will be dependent on the product in question but could be as simple as adding rules to an Apache .htaccess file.
• Pay particular attention to auth. portals that use Active Directory as their identity provider. You'll want to be especially vigilant with these. They're high value targets that commonly lead to network breaches, business email compromise, etc. Oh, and don't just look at web forms. Find those pesky NTLM web authentication endpoints!

2. Legacy and/or Unnecessary Broadcast Traffic

TLDR: Internal networks are very chatty. A lot of this traffic is for legacy support, is unnecessary, and/or can be easily abused to compromise user accounts or workstations. Disabling this traffic will have significant impact on an attacker's ability to compromise the Active Directory environment (users and/or workstations) from within the network.

The What:
Protocols such as LLMNR and NBNS are used as a fallback method to resolve domain names, in the event that DNS fails. Additionally, protocols such as IPv6 and mDNS are generally unnecessary for internal, enterprise networks. These protocols are widely targeted during internal penetration tests due to their susceptibility to poisoning. Disabling these protocols is relatively easy and has a profound positive impact.

The Why:
In our experience, we abuse these legacy protocols on about 80% of our internal penetration tests. It's the most common method through which we gain initial domain credentials and almost always leads to domain escalation and lateral network movement. Fixing these issues will have a significant impact against insider threats and unauthorized internal threat actors.

The How:
We recommend, amongst other practices, the following:

• Update computer policy to Turn OFF Multicast Name Resolution
• Update Network Connections properties to Disable NetBIOS over TCP/IP
• Disable IPv6 via GPO
• Set a static proxy value for all browsers in the network
• Disable mDNS, if possible
• Added Bonus: Require SMB signing to prevent relaying

3. Active Directory Password Blacklisting

TLDR: Passwords remain a highly sought after target; credential acquisition is often the first and most important stage in an attack chain. Password length and complexity alone may not be sufficient to protect accounts from compromise. Instead, blacklist common base words and patterns to prevent trivial recovery via online and offline attacks.

The What:
Most organizations enforce a password policy consisting of uppercase, lowercase, numeric, and special characters with a minimum length of 10. A forced password change cadence of 90-days is typical. Guess what? Spring2022! meets all those requirements. Users like patterns - they're easy to remember - so, they choose Summer2022! when required to change their password. Easy for them; easy for an attacker. Passwords selected using a simple baseword or a password that was publicly disclosed in a breach greatly increases the likelihood of an attacker guessing a user's password or, in the event that a hash is acquired, cracking it offline. We need better alternatives than length and complexity...

The Why:
One of the first things we try on a pentest is to guess a set of user credentials. One of the first passwords we'll try is of the format SeasonYYYY! or MonthYYYY!. We see all sorts of patterns based off company name, sports teams, cities, first names, etc. Restricting users from setting passwords based off certain basewords or words disclosed in password breaches greatly reduces the likelihood of account compromise, and it's fairly cheap!

The How:
We recommend, amongst other practices, the following:

• Implement it using Azure AD Password Protection
• Implement it with bubble gum and duct tape

So, we genuinely had a difficult time narrowing the list to three, given there are so many "what ifs" and business-specific requirements. Here are a few additional on-a-budget wins we highly recommend.

Multi-Factor Auth.

Ok, this might not be cheap or easy, but it needs to be included because of its importance. Protect, at the least, business email portals, VPN portals, and sensitive management portals with MFA.

Increase Password Length

Increasing password length exponentially increases the keyspace and recovery times. Increase the length to further fortify accounts against compromise.

Printer Credentials

Printers are attractive targets. They commonly run with default or guessable passwords. Countless times we've exploited this to retrieve Active Directory credentials and get a foothold on the domain. Just change the administrative password. Problem solved.

Local Admin Controls

Too often, we still encounter local administrator accounts with shared passwords across several hosts. That's bad. It turns it into a pseudo-domain-admin. Implement Microsoft's Local Account Password Solution and disable remote logon for local administrators.

While you're at it, you should review the users with local admin rights in your organization. While it might be a fight, removing these rights and enforcing a "least privilege" policy will limit the opportunity of abuse should their account get compromised.

Active Directory Certificate Services ("ADCS")

Microsoft's PKI is a complex beast. Recently disclosed vulnerabilities make ADCS a prime target for abuse. Harden it. It's a common target that leads to privilege escalation, user impersonation, and persistence.

Enable Conditional Access

Whether you have MFA or not and whether you have strong passwords in place, enabling Conditional Access allows you to provide fine-grained controls over the user access based on a variety of factors. It can reduce the likelihood or impact of account compromise.

Get to the Point

This is short and sweet because the info is out there, and we just want to direct people to the collective, without the "jump to the recipe" bloat. We are not going to reiterate what has already been provided numerous times elsewhere on the interwebs. What we are going to state is the reinforcement that this particular vulnerability has a very large blast radius. The reach is going to be far and wide, so please perform the necessary due-diligence.

That is easier said than done, so we are providing a couple of references. Arguably the most prevalent resource is via the gov's CISA GITHUB repository. Leverage this resource for up-to-date guidance regarding CVE-2021-44228. They have done an excellent job with updating content as it becomes available.

CVE-2021-44228

Further, there may be software in an organization where the use of Log4j is in use but unsure if it is vulnerable, or unsure if the overall software bill of materials includes the affected software. For this situation, leverage reputable Log4j detection tooling.

Local System Scanner

Fox-IT Log4j Local Scanner

Remote System Scanner

Fullhunt Log4j Remote Scanner

YARA Rules

Florian Roth Log4j YARA Rules

Conclusion

This is going to be around for years. We are actively on numerous environments and every single one of them has Log4j. Please take the time to increase your awareness, implement the necessary remediation, and take the high road to safe-guarding persons and property.

Reach out if you need help detecting and protecting. At your service. Stay safe.