Brandon Perry - Gray Hat C: A Hackers Guide to Creating and Automating Security Tools

A Hackers Guide to Creating and Automating Security Tools

Brandon Perry

San Francisco

GRAY HAT C#. Copyright 2017 by Brandon Perry.

All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher.

ISBN-10: 1-59327-759-8
ISBN-13: 978-1-59327-759-8

Publisher: William Pollock
Production Editors: Alison Law and Serena Yang
Cover Illustration: Jonny Thomas
Interior Design: Octopod Studios
Developmental Editors: William Pollock and Jan Cash
Technical Reviewer: Brian Rogers
Copyeditor: Barton D. Reed
Compositor: Susan Glinert Stevens
Proofreader: Paula L. Fleming
Indexer: BIM Creatives, LLC.

For information on distribution, translations, or bulk sales, please contact No Starch Press, Inc. directly:
No Starch Press, Inc.
245 8th Street, San Francisco, CA 94103
phone: 1.415.863.9900;
www.nostarch.com

Library of Congress Cataloging-in-Publication Data

Names: Perry, Brandon, author.

Title: Gray hat C# : a hacker's guide to creating and automating security tools / Brandon Perry.

Description: San Francisco : No Starch Press, Inc., [2017]

Identifiers: LCCN 2017002556 (print) | LCCN 2017005221 (ebook) | ISBN

9781593277598 (pbk.) | ISBN 1593277598 (pbk.) | ISBN 9781593278311 (epub)

| ISBN 1593278314 (epub) | ISBN 9781593278328 (mobi) | ISBN 1593278322

(mobi)

Subjects: LCSH: C# (Computer program language) | Automatic control--Computer

programs. | Computer security.

Classification: LCC QA76.73.C154 P44 2017 (print) | LCC QA76.73.C154 (ebook)

| DDC 005.8--dc23

LC record available at https://lccn.loc.gov/2017002556

No Starch Press and the No Starch Press logo are registered trademarks of No Starch Press, Inc. Other product and company names mentioned herein may be the trademarks of their respective owners. Rather than use a trademark symbol with every occurrence of a trademarked name, we are using the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.

The information in this book is distributed on an As Is basis, without warranty. While every precaution has been taken in the preparation of this work, neither the author nor No Starch Press, Inc. shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in it.

C# CRASH COURSE

FUZZING AND EXPLOITING XSS AND SQL INJECTION

FUZZING SOAP ENDPOINTS

WRITING CONNECT-BACK, BINDING, AND METASPLOIT PAYLOADS

AUTOMATING NESSUS

AUTOMATING NEXPOSE

AUTOMATING OPENVAS

AUTOMATING CUCKOO SANDBOX

AUTOMATING SQLMAP

AUTOMATING CLAMAV

AUTOMATING METASPLOIT

AUTOMATING ARACHNI

DECOMPILING AND REVERSING MANAGED ASSEMBLIES

READING OFFLINE REGISTRY HIVES

As an attacker or defender developing software, one obviously needs to decide which language makes the most sense to use. Ideally, a language wont be chosen simply because it is what the developer is most comfortable with. Rather, a language should be chosen based on answering a series of questions such as the following:

What are my primary target execution environments?

What is the state of detection and logging for payloads written in this language?

To what level does my software need to maintain stealth (for example, memory residence)?

How well is the language supported for both the client side and the server side?

Is there a sizable community developing in this language?

What is the learning curve and how maintainable is the language?

C# has some compelling answers to these questions. As to the question about the target execution environment, .NET should be an obvious candidate for consideration in a Microsoft-heavy environment because it has been packaged with Windows for years. However, with the open-sourcing of .NET, C# is now a language that can drive a mature runtime on every operating system. Naturally, it should be considered an extremely enticing language for true cross-platform support.

C# has always been the lingua franca of .NET languages. As you will see in this book, you will get up and running with C# in no time thanks to its low barrier to entry and massive developer community. Additionally, with .NET being a managed, type-rich language, compiled assemblies lend themselves to being trivially decompiled to C#. Therefore, someone writing offensive C# need not necessarily develop their capabilities in a vacuum. Rather, one can pull from a wealth of .NET malware samples, decompile them, read the equivalent of their source code, and borrow their capabilities. They could even go so far as to employ the .NET reflection API to load and execute existing .NET malware samples dynamicallyassuming, of course, theyve been reversed sufficiently to ensure they do nothing subversive.

As someone who has spent years bringing offensive PowerShell into the mainstream, my efforts have brought about massive security improvements and logging facilities in the wake of the surge of PowerShell malware. The latest version of PowerShell (v5 as of this writing) implements more logging than any other scripting language in existence. From a defenders perspective, this is fantastic. From a pentester, red teamer, or adversarys perspective, this increases the noise of ones attack significantly. For a book about C#, why do I mention this? Although it has taken me years to realize it, the more PowerShell I write, the more I acknowledge that attackers stand to gain far more agility by developing their tools in C# rather than doing so strictly in PowerShell. Allow me to explain:

.NET offers a rich reflection API that allows one to load and dynamically interact with a compiled C# assembly in memory with ease. With all the additional introspection performed on PowerShell payloads now, the reflection API enables an attacker to better fly under the radar by developing a PowerShell payload that only serves as a .NET assembly loader and runner.

As Casey Smith (@subTee) has demonstrated, there are many legitimate, Microsoft-signed binaries present on a default installation of Windows that serve as a fantastic host process for C# payloadsmsbuild.exe being among the stealthiest. Using MSBuild as a host process for C# malware embodies the living off the land methodology perfectlythe idea that attackers who can blend into a target environment and introduce a minimal footprint will thrive for a longer period of time.

Antimalware vendors to date still remain largely unaware of .NET assembly capabilities at runtime. Theres still enough unmanaged code malware out there that the focus hasnt shifted to effectively hooking the .NET runtime to perform dynamic runtime introspection.

With powerful access to the massive .NET class library, those comfortable with PowerShell will find the transition to C# a relatively smooth one. Conversely, those comfortable with C# will have a lower barrier to entry in transferring their skills to other .NET languages such as PowerShell and F#.