h1

Cobalt Strike 2.5 – Advanced Pivoting

July 29, 2015

I spend a lot of my red time in the Access Manager role. This is the person on a red team who manages callbacks for the red cell. Sometimes, I like to grab a Beacon and drive around a network. It’s important to get out once in a while and enjoy what’s there. Cobalt Strike 2.5 is all about cruising around networks.

Lateral Movement++

This release adds native lateral movement options to Beacon. Use the psexec_psh, winrm, and wmi commands to deliver a Beacon to a target using PowerShell to avoid touching disk. For you old school types, a psexec command is available to deliver a Beacon to a target with an Artifact Kit service executable.

You’ll likely notice that Cobalt Strike’s lateral movement options do not accept credentials, hashes, or other credential material. Keeping with Cobalt Strike’s operating philosophy, these lateral movement options rely on what’s in your access token to authenticate with a remote system. If you want to pass-the-hash with Beacon; use mimikatz to create a token that passes your hash. If you need to pass credentials, use Cobalt Strike 2.5’s make_token command to create a token to pass the credentials you provide.

Named Pipe Stager

Cobalt Strike’s best payload for lateral movement is the SMB Beacon. This Beacon uses a named pipe to receive commands from and relay output through another Beacon. A named pipe is an inter-process communication mechanism on Windows. Named pipes also work host-to-host to allow two programs to communicate with each other over the network. This traffic is encapsulated in the SMB protocol.

The SMB beacon is awesome but it had a weakness. It’s too big to use with attacks like psexec_psh. Cobalt Strike 2.5 solves this problem with its named pipe stager. This tiny stager delivers the SMB Beacon to a remote target over a named pipe. This stager works well with Beacon’s new lateral movement options that don’t touch disk. This is quite an upgrade from the previous best practices.

Pivoting Process-to-Process

Red Teams pivot, not just host-to-host, but process-to-process on the same host. This need is usually driven by egress and evasion concerns. A process run as an unprivileged user may have the ability to egress. As soon as you elevate, you may run into difficulties if that elevated process can’t communicate out.

Cobalt Strike 2.5 uses the SMB Beacon to help with this problem. Beacon features to include its Bypass UAC attack and new spawnas command [use credentials to spawn a payload; without touching disk] accept the SMB Beacon as a target payload. This greatly improves Cobalt Strike’s options to work through one egress channel.

Reverse Port Forwards

Cobalt Strike 2.5 also adds reverse port forwarding. Beacon’s new rportfwd command will bind a port of your choice on a compromised target. When someone connects to this port, Cobalt Strike’s team server will establish a connection to a forward host and port of your choosing. It will then relay traffic, via Beacon, between this new connection and the client connected to your Beacon. Now, you can use compromised systems as arbitrary redirectors. ☺

Check out the release notes to see a full list of what’s new in Cobalt Strike 2.5. Licensed users may use the update program to get the latest. A 21-day Cobalt Strike trial is also available.

h1

WinRM is my Remote Access Tool

July 22, 2015

One of my favorite blog posts last year was Adversary Tricks and Treats from CrowdStrike. In this post, CrowdStrike details the tradecraft of an actor they dub Deep Panda. In an attempt to skirt advanced malware hunting capability, Deep Panda leverages native tools to control target systems and spread laterally in a network. With the exception of their foothold, they don’t use malware to complete their objectives.

This is an important idea. One of my favorite red team tasks is to provide a credible adversary to exercise new ideas for network defense. There’s a positive shift away from the passive blinky boxes to the inquisitive analyst who has tools to ask questions at scale. As red operators, we have a neat opportunity to nurture and grow these analysts into formidable defenders.

All that future talk aside, it’s important to think about how to do this. One way I do it is by looking at different ways to operate. I think it’s important to have multiple concepts of offense and ways to simulate an on-going offensive operation. One of my favorite ways now is to play like Deep Panda and limit my use of malware as much as possible.

I’m keenly aware that skilled network defenders watch some assets more than they watch others. A domain controller is no-man’s land. A skilled team armed with techniques that don’t scale will watch their domain controller’s like hawks when they know a red team is exercising them. Workstations are… less important.

I like to live on the workstations with my malware and use native tools to interrogate and control servers as much as possible.

There are a lot of ways to abuse a trust relationship to run commands on a remote system. at, schtasks, sc, and wmic are among my favorites. I’m a WinRM fan too.

WinRM is the Windows Remote Management service. It listens on port 5985. It’s off by default, but some system administrators turn it on to enable easy remote management of their servers [hence the name, right?]

When WinRM is on, you can use PowerShell to remotely interrogate a server and control it. Or, if you’re feeling lucky, you can turn WinRM on yourself. Here’s how to enable WinRM via Beacon:

powershell Enable-PSRemoting -Force

The output will look like this:

winrm

WinRM does require a trust relationship with the target system. You’ll need a token for a domain user that is a local administrator to the target. You can steal one of these, make one with runas, or use Mimikatz to create a token to pass a password hash.

To control a target via WinRM from Beacon, here’s the syntax:

powershell InvokeCommand -ComputerName TARGET -ScriptBlock { dir c:\ }

PowerShell will run, via WinRM, whatever you specify inside of the script block. After this command completes, PowerShell will return the output to you.

The ability to run commands on a remote target AND get output back is nice. In most cases, this is enough capability to operate and achieve an objective. One of my favorite things though is the ability to run Mimikatz this way. PowerSploit’s Invoke-Mimikatz cmdlet allows you to specify a -ComputerName argument. Fun fact: this argument can be array of systems to run Mimikatz on. With this option specified, PowerSploit will run mimikatz via WinRM, in memory on the remote target, and report the output back to you.

Here’s the syntax to do it:

powershell-import /local/path/to/PowerSploit/Exfiltration/Invoke-Mimikatz.ps1
powershell Invoke-Mimikatz -ComputerName TARGET

Here’s a video of these concepts in action:

Between Mimikatz and the ability to run arbitrary commands remotely, I have a lot of operating capability right there. If you want to emulate a long-term embedded actor who does things a little differently, this is certainly a good TTP to try out.

h1

Models for Red Team Operations

July 9, 2015

Recently, I had an email from someone asking for a call to discuss different models of red team operations. This gentlemen sees his team as a service provider to his parent organization. He wants to make sure his organization sees his team as more than just dangerous folks with the latest tools doing stuff no one understands. This is a fair question.

In this post, I’ll do my best to share different models I see for red team operations. By operations, I mean emulating the activities of a long-term embedded adversary in a network, one that works from a remote location. This ability to gain, maintain, and take action on access over a (potentially) long period of time is a different task from analyzing an application to find flaws or quickly enumerating a large network to identify misconfigurations and unpatched software.

You may ask, what’s the point of emulating a (remote) long-term embedded adversary? Two words: Security Operations. I’m seeing a shift where organizations are leveraging their red assets to validate and improve their ability to detect and respond to intrusions.

With all of that said, let’s go through a few of the different models:

Full Scope Penetration Tests

A full scope penetration test is one where a hired or internal team attempts to gain a foothold into their customers environment, elevate their rights, and steal data or achieve some desired effect. These engagements mimic the targeted attack process an external actor executes to break into an organization. When a lot of my peers think about red team operations these assessments are immediately what comes to mind.

Full scope penetration tests provide a data point about the state of a security program, when all aspects are exercised in concert against an outside attacker. Unfortunately, full scope assessments are as much a test of the assessor as they are of the organization that commissioned these tests. They are also expensive and assessors have to cope with restrictions that are not placed onto a real adversary [less time, fewer resources, compliance with the law].

Given time, resources, and competent execution, a full scope engagement can offer valuable insight about how an external actor sees an organization’s posture. These insights can help identify defensive blind spots and other opportunities for improvement. These engagements are also useful to re-educate executives who bought into the hype that their organization is un-hackable. Making this point seems to be a common driver for these assessments.

Long-term Operations

I see several red teams building long-term operations into their services construct. The idea is that no organizational unit exists in isolation of the others. The organizational units that commission engagements from their internal assets are not necessarily the organizational units that are most in need of a look from a professional red team. To deal with these situations, some red teams are receiving cart blanche to gain, elevate, and maintain access to different organizational units over long period time. These accesses are sometimes used to seed or benefit future engagements against different organizational units.

Long-term Operations serve another purpose. They allow the red team to work towards the “perfect knowledge” that a long-term embedded adversary would have. This perfect knowledge would include a detailed network map, passwords for key accounts, and knowledge about which users perform which activities that are of value to a representative adversary.

It’s dangerous to require that each red team engagement start from nothing with no prior knowledge of a target’s environment. A long-term embedded adversary with a multi-year presence in a network will achieve something that approximates perfect knowledge.

For some organizations, I’m a fan of this approach and I see several potential benefits to it. The perfect knowledge piece is one benefit, but that is something an organization could white card if they wanted to. There’s another key benefit: our common understanding of long-term offensive operations is weak at best. Maintaining and acting on access over a long period of time requires more than a good persistence script and a few VPS nodes. The organizations that take time to invest in and get good at this approach will find themselves with interesting insights about what it takes to keep and maintain access to their networks. These insights should help the organization make investments into technologies and processes that will create real pain for a long-term embedded actor.

War Games

Several organizations stage red vs. blue war games to train and evaluate network defense staff. These exercises usually take place in a lab environment with multiple blue teams working to defend their representative networks against a professional opposing force. The role of this opposing force is to provide a credible adversary to train participants and keep pressure on them throughout the event.

Each of these events is different due to their different goals. Some events white card the access step completely. Some also white card the perfect knowledge of the long-term embedded adversary. It all depends on the event’s training objectives and how the organiser’s want to use their professional red team assets.

To an outsider, large scale Red vs. Blue events look like a chaotic mess. The outsider isn’t wrong. Red vs. Blue events are a chaotic mess. They’re chaotic because they’re fast paced. Some compress a multi-year attack scenario into an event that spans days or weeks.

There’s value to these events though. These events provide a safe opportunity to exercise processes and team roles in a fast-paced setting. They’re also an opportunity to field immature or new technologies to understand the benefit they can provide. Unlike more structured tests, these events also give blue participants opportunities to observe and adapt to a thinking adversary. Done right, these events encourage full disclosure between red and blue at the end so participants can walk away with an understanding of how their blue TTPs affected the professional adversary.

Threat Scenarios / Cyber Security Exercises / Attack Simulations

Another use for red assets is to help design and execute cyber security exercises to train and assess network defense teams. These exercises usually start with a plausible scenario, a representative or real actor, and a realistic timeline.

The red asset’s job is to generate realistic observable activity for each part of the timeline. The red operator is given every white card they need to execute their observable effect. Each of these carefully executed items becomes a discussion point for later.

These exercises are a great way to validate procedures and train blue operators to use them. Each unique generated activity is also an opportunity to identify procedure and technology gaps in the organization.

While this concept is new-ish to security operations, it’s by no means new. NASA has had a concept of an Integrated Training Team led by a Simulation Supervisor since the beginning of the US space program. NASA’s lessons learned in this area is a worthwhile study for security professionals. When I think about emerging job role of the Threat Emulator, I see these folks as the equivalent of NASA’s Simulation Supervisors, but for Security Operations.

Who is doing this?

I see several red teams re-organizing themselves to serve their organizations in different ways from before. Established teams with custom tools for long-term operations are trying to retool for engagements that require full disclosure afterwards. Other teams mirror external consulting firms in their services. These teams are now trying to give their leadership a global long-term perspective on their organization’s security posture. Day-to-day these teams are working towards the credibility, capability, and skills to bring the benefits of long-term operations to their organization. I see a trend where many internal red teams are expanding their services to benefit their organization’s at the tactical and strategic levels. It’s an exciting time to be in this area.

h1

Cobalt Strike Penetration Testing Labs (Download)

June 4, 2015

My primary conference give away is a DVD with a self-contained penetration testing lab. This DVD covers the Metasploit Framework‘s capability to target a server. It also covers the client-side attack process in Cobalt Strike. It’s a pretty neat set of labs and they don’t take too long to go through.

Cobalt Strike Boxed Set

I’ve had several requests to put these labs online. If you’re one of those interested parties, then today is your lucky day. The Cobalt Strike Pen Testing Lab DVD material is now available for download.

To start, you’ll want to grab the necessary virtual machines:

1. Morning Catch (Phishing Target)
http://www.advancedpentest.com/downloads/morningcatch.zip.torrent

2. Metasploitable 2
http://sourceforge.net/projects/metasploitable/files/Metasploitable2/

3. Xubuntu Attack VM with CS dependencies and stuff to support the labs
http://www.advancedpentest.com/downloads/xubuntu.zip.torrent

Next, you’ll want to download the penetration testing lab book. Last, you’ll need to grab a trial of Cobalt Strike and install it on the Xubuntu virtual machine above.

Once you have these things, you’re ready to rock. If you get stuck, here’s a video of me going through the labs:

Enjoy!

h1

How to Pass-the-Hash with Mimikatz

May 21, 2015

I’m spending a lot of time with mimikatz lately. I’m fascinated by how much capability it has and I’m constantly asking myself, what’s the best way to use this during a red team engagement?

A hidden gem in mimikatz is its ability to create a trust relationship from a username and password hash. Here’s the mimikatz command to do this:

sekurlsa::pth /user:USERNAME /domain:DOMAIN /ntlm:HASH /run:COMMAND

The sekurlsa:pth command requires local administrator privileges. This command spawns the process you specify and modifies its access token. The local Windows system will still think the process was run by your current user. The parts of the token designed to support single sign-on will reference the username, domain, and password hash you provide.

If you use the above to spawn another payload (e.g., Meterpreter, Beacon); your actions that attempt to interact with a remote network resource will use the username, domain, and password hash you provide to authenticate.

In practice, spawning a new payload to pass-the-hash is a pain. It’s much easier to spawn a bogus process (e.g., calc.exe) and steal its token. Beacon’s steal_token command will impersonate a token from another process. The token stolen from our bogus process will continue to reference the username, domain, and password hash you provide. Any actions to interact with a remote resource, while Beacon holds this token, will pass the hash for us.

Let’s assume I have a foothold in a target environment and I’ve elevated my privileges. Here’s how I’d use this for lateral movement with Beacon:

1) Run hashdump to dump password hashes for the local users.

hashdump

2) Run mimikatz sekurlsa::pth /user:Administrator /domain:. /ntlm:… /run:”powershell -w hidden”

pth

We do powershell -w hidden to create a process without putting a Window on the desktop. Mimikatz doesn’t hide Windows for the processes it creates.

3) Use steal_token 1234 to steal the token from the PID created by mimikatz

stealtoken

4) Use shell dir \\TARGET\C$ to check for local admin rights

admincheck

5) Try one of the lateral movement recipes (wmic, sc, schtasks, at) from this blog post to take control of the system.

lateral

To get a feel for how this works, I’ve put together a video:

This method of pass-the-hash has several advantages over traditional pen tester methods. Which advantage resonates with you will depend on the situations you face.

When I work with a mature network defense team, I try to avoid non-asynchronous communication. This means I can not speed up my Beacon to tunnel PsExec or another Metasploit module through my Beacon. This interactive communication will get caught right away. This plays well with an asynchronous post-exploitation workflow.

This method also gives me a great deal of flexibility. I’m relying on Windows to pass my credential material for me. What I do to interact with a remote network resource is up to me. If I’m only interested in data, I can list and copy files via a UNC path to the target. If I want to execute code, I have options beyond the service control manager to do so. When dealing with a mature target, this is important.

Finally, I prefer to use native tools over hacker tools to carry out my actions. I favor native tools because they blend in better and they’re more likely to work consistently. This method of pass-the-hash caters well to this preference.

h1

An unnecessary addiction to DNS communication

May 14, 2015

I regularly hear stories from my users about how they got past a tough situation and had success that they claim was not possible without Cobalt Strike. As a developer, these emails are fun to read, and they give me a lot of job satisfaction.

One of the features these users love is DNS Beacon. Beacon is Cobalt Strike’s post-exploitation payload to model an advanced attacker. Beacon has DNS, HTTP, and SMB variants. The DNS Beacon is a flexible beast. It beacons over DNS, but downloads tasks over HTTP, DNS A records, or DNS TXT records. It’s possible to stage DNS Beacon over DNS TXT records or an HTTP GET request.

Many of my users use DNS Beacon to defeat very tough egress restrictions. That’s cool and for a while, we’ve had a free pass with DNS. Today, a few products are catching up to the idea that DNS is a communication channel attackers will abuse. We’re starting to see common sense heuristics to detect this abuse and help a network defense team identify and stop it.

Some of my users are feeling the pain of this. They write to me and ask for ideas on how to make Cobalt Strike’s DNS communication work against heuristic X. These are interesting emails because the right answer is context dependent.

Sometimes, there’s some play in DNS as a communication channel. Cobalt Strike’s Beacon is a flexible post-exploitation agent and I put a lot of power into my user’s hands. Other times, DNS communication is off of the table and it’s time to adapt. In this post, I’ll take you through my thoughts on these topics.

Staging over DNS

The most fragile part of the DNS communication options in Cobalt Strike is the staging process. DNS Beacon’s stager uses DNS TXT records to download Beacon and inject it into memory. I use TXT records to do this because it’s an efficient way to transmit a payload over DNS. By efficient, it’s still over one thousand requests. If an organization is watching for DNS abuse, this will stand out.

If staging is your pain point, you have the option to export the DNS Beacon without a payload stager. Attacks -> Packages -> Windows Executable (S) is the dialog to export a stageless Beacon. You get the option of raw position independent code, an executable, a service executable, PowerShell, a 32-bit DLL, and a 64-bit DLL. One of these options is bound to satisfy your needs to get a Beacon onto a box.

If your target can egress over HTTP, Cobalt Strike’s DNS Beacon can stage over HTTP too. I put this last because a lot of times folks use DNS Beacon to control systems that can’t directly reach the internet. We’ll go into this use case a little more in a moment.

Flexible DNS Communication

I mentioned earlier that the technologies that detect DNS communication are heuristics. If you feel like you’re getting detected, it would help to figure out how that detection works, and see if there’s a Cobalt Strike option to get around it.

First, Cobalt Strike communicates over DNS two different ways. The mode dns-txt command tells DNS Beacon to use DNS TXT records to download its tasks. This method of DNS communication is common in malware that uses DNS and it’s probably the method most prone to detection. I like the DNS TXT record channel, when I can get away with it, because it’s the more efficient of the two channels.

The mode dns command tells DNS Beacon to download its tasks with A records. If you have a 32 byte tasking, DNS Beacon will issue eight requests to download that tasking. Sometimes you can get away with DNS A records as a channel when TXT records won’t fly. Just know that it will take awhile for Beacon to download large taskings from you. To get the most from any tool, you should always know how it works and the limitations of each option.

To send data back to you, both the DNS A and DNS TXT record channels ask the target system to resolve [encoded and encrypted data].yourmaliciousdomain.com. This is a gross simplification, but it’s fine for this discussion.

Some technologies detect DNS abuse by looking for long hostnames in a DNS record request. Cobalt Strike’s Malleable C2 technology gives you control over this. The maxdns option allows you to restrict the length of these requests. It will take longer for DNS Beacon to send data back to you, but this option may also help you avoid detection.

Other technologies detect DNS abuse by looking at how many requests are made to a given domain in a short period of time. Sometimes, this threshold is high. If this is the case, here’s my advice:

1. Use the Malleable C2 option sleeptime to change the default sleep time between each Beacon interval. I recommend 1 to 3 minutes at a minimum for these situations.

2. Swear off interactive command and control. This means you do not get to lower the sleep time of your Beacon. You’ll need to conduct all of your post-exploitation in an asynchronous way. Asynchronous post-exploitation is the only way to operate against harder targets. There’s tradecraft and tool support for this. Both are getting better over time.

3. Use multiple domains with your DNS Beacon. If a technology blocks a domain, hopefully you’ll just lose use of that domain, but not your access. If a technology kills your process, that’s a different
situation altogether.

I primarily use DNS Beacon as a persistent lifeline to spawn an access back into a network. On those rare instances where DNS is the only possible channel[tm], I continue to follow best practice and split my infrastructure up into different tiers. I use a post-exploitation server for post-exploitation activity. I avoid any interactive activity from my long-haul server for persistent callbacks. If you’re convinced that DNS is your only channel and you’re under this type of scrutiny, I recommend you fortify your key accesses to separate infrastructure. You don’t want a post-exploitation misstep to get you kicked out of your target’s network.

I like HTTP footholds!

For my userland footholds in a network, I use the HTTP Beacon as my workhorse payload. If it’s possible for a user to browse to websites with Internet Explorer, it’s probably possible to egress with HTTP Beacon as well. Possible is different from turn-key though. To defeat tough egress restrictions, as with all hacking activities, you have to get enough of the details right.

First, I make sure to have fully qualified domain names for all pieces of my infrastructure. I never try to egress to an IP address. For really tough situations, I use redirectors heavily. I also take care to stage through one redirector and configure the beaconing step to happen through the others. Cobalt Strike separates these options for a reason.

Some proxy servers use URL whitelisting to defeat malicious activity. I once got past this with Malleable C2. I used parameter q “www.youtube.com” to add ?q=www.youtube.com to each GET and POST request. The device in place checked for a whitelisted string in the whole URL. It didn’t care where it was.

I also take steps to match my Malleable C2 profile to the workstations I expect to egress from. A low hanging fruit item is to make my User-Agent match the User-Agent of the browser the user most commonly uses. The System Profiler is a great reconnaissance technology to capture this information.

Does the target environment have a HIPS product that limits which processes can egress? Fine! You can play this game and win. One of my favorite tricks is to modify the macro attack to spawn Internet Explorer and inject my Beacon payload into it. The same option exists for Cobalt Strike’s Applet Attacks [just download the Applet Kit, modify it, recompile, and rock it out!]

Pay attention to the Content-Type header as well. Some proxy devices whitelist which Content-Types are allowed. Malleable C2 lets you make HTTP Beacon look like something other than an arbitrary binary blob. It’s great for these situations.

Pivoting with Beacon

I speculate that a lot of my users like DNS Beacon for the same reason I like it for persistence. DNS Beacon will likely communicate with you, when run as SYSTEM, and from servers that can’t normally egress. This is a fine use for DNS Beacon, but if you have one HTTP foothold as a user on a workstation–there’s a better way to assume control of other Beacons. Let’s talk about the SMB Beacon.

The SMB Beacon is a Beacon variant that uses a named pipe to link to another Beacon. All of the SMB Beacon’s tasks and output come and go through the parent Beacon. It’s possible to link multiple Beacons together into a chain.

I use SMB Beacon a lot for privilege escalation. I may know I can’t egress as SYSTEM, but if I run an SMB Beacon, I can egress through my Beacon running in a user process. It’s nice.

I also use SMB Beacon for lateral movement. Named pipes work for host to host communication and this traffic is encapsulated in SMB. Those juicy Windows workstations that can’t reach the internet often have port 445 open. The SMB Beacon is the perfect payload to control these servers and make them egress through a user process on a workstation. I’m a big fan of operating this way.

When HTTP egress is possible, anywhere on a network, DNS communication is not necessary. It’s much easier to use that foothold to help all of my SMB Beacons reach me.

What’s the point?

If a network architecture or defense technology successfully mitigates a tactic, then it’s time to switch tactics. No single technique is the right answer for all situation into perpetuity. If you’re finding yourself challenged by a defense, think about what it’s doing. Know your tools and their options. You may have some room to get past that defense and continue on your merry way. If that’s not enough, try something else. This ability to reason about defenses and adapt to a situation is the stuff of great red team operators.

h1

Under the DIRWALK (Lyrics)

May 5, 2015

To the tune of Under the Boardwalk written by Kenny Young and Arthur Resnick, recorded by The Drifters.

Oh, when the domain is done and on all servers you’re root
And the hashes are so many, you wish your cracking rig were fireproof
Under the DIRWALK, down by the C:
Running my implant as SYSTEM is where I’ll be

(Under the DIRWALK) Out to the remote node
(Under the DIRWALK) We’ll be exfiling some stuff
(Under the DIRWALK) NSM watching all of us
(Under the DIRWALK) We’ll be doing what we want
Under the DIRWALK, DIRWALK

From the screenshot you see, a user checking their ‘mail
Mmm, you can almost take the plans to all the stuff they sell
Under the DIRWALK, down by the C:, yeah
Running my implant as SYSTEM is where I’ll be

(Under the DIRWALK) Out to the remote node
(Under the DIRWALK) We’ll be exfiling some stuff
(Under the DIRWALK) NSM watching all of us
(Under the DIRWALK) We’ll be doing what we want
Under the DIRWALK, DIRWALK

Oh, under the DIRWALK, down by the C:, yeah
Running my implant as SYSTEM is where I’ll be

(Under the DIRWALK) Out to the remote node
(Under the DIRWALK) We’ll be exfiling some stuff
(Under the DIRWALK) NSM watching all of us
(Under the DIRWALK) We’ll be doing what we want
Under the DIRWALK, DIRWALK

Follow

Get every new post delivered to your Inbox.

Join 16,100 other followers