This presentation was given to a group of SFS students at GW. It's designed to be semi-case study driven on the problems I've encountered on assessments and how programming can help solve them.

1. Pen Testing
Devevelopment
Christopher Truncer

2. uid=0(@ChrisTruncer)
● Christopher Truncer (@ChrisTruncer)
○ Open Source Software Developer, Veil Framework
Developer, Florida State Seminole
● Red Teamer, Pen Tester, and Security
Researcher for Mandiant

3. What’s this talk about?
● How I got started
● Security through Offense
○ EyeWitness
○ #avlol
○ Own the Exfil
○ Misconfigurations
● What (I think) makes successful hackers
○ Your drive
○ Scripting/Programming
● Tempt the demo gods throughout

4. How I Started
● College
○ College computer security class
○ Hack my roommate
■ “Wow, hacking is real”
● Tech background before Security
○ Windows Admin
○ Linux Admin - to learn
● Started the plunge into security
○ No development experience

5. First Steps with Development
● Start small
○ Veil wasn’t built in day :)
● Fix problems/tasks you always see
● Google and Stack Overflow
● Just try it...
● Nearly all upcoming case studies involve writing
some code

6. When Coding...

8. Developing for
Offensive Operations

9. My Development Philosophy
● Develop a POC that does what you want
● Clean up your code, and add comments!
● Make it usable by everyone, not just you
● Contribute back and make it public
● Maintain your project

10. Version Control
● Use anything you’re comfortable with, but use it
○ git - my choice (look at Github, it’s free)
○ svn
○ cvs
○ etc…
● You will mess your code up
● You will delete your tools/scripts
● You will be thankful for checking in your code

11. EyeWitness

12. EyeWitness
● Problem: When dropped in large network
segments, we can see hundreds, if not
thousands of web applications. How do we know
which to attack?

13. EyeWitness
● Solution: Automate everything I would manually
have to do
● Mandatory:
○ Screenshot web applications
○ Check for default credentials
○ Generate a usable report
● Optional:
○ Make report “sections”
○ Grab server headers

14. Google!

15. StackOverflow

16. Proof of Concept

17. Make it Usable
● File Input
○ File, NMap, Nessus
● Web Timeouts
● Default Credential Checks
● Report Generation
○ Create Sections
■ High Value Targets
■ Error Section
■ etc.

19. EyeWitness Stats
● Originally: 409 Lines
● Now: 3402 Lines
● Reasons:
○ Login Signatures
○ Multi-Threading
● Guess for the real
reason?

21. #avlol

22. The Veil-Framework
● Problem: Antivirus can’t catch malware, but it
catches pentesters
● Goal: Bypass antivirus as easily as professional
malware developers
● Solution: A python-based framework for
generating shellcode and meterpreter injectors

23. As Always, Ask the Google

24. Have a POC… Next?
● Research obfuscation methods
○ Look at existing malware
○ Try encryption routines
● Generate random files from a template
○ Framework might help
● Automate as much as possible
○ I probably should make a framework...

25. Veil 1.0 - Released
● Small, single file
script
● Limited payloads
● It worked… better
than it really should

26. Next Steps...
● Don’t use a single script
○ Maintenance can be a pain
○ Not easily extensible
○ A framework would be nice...
● Find a mentor
○ Ability to ask questions is invaluable
○ Learning & Collaboration opportunities

27. Teamed Up
● Teamed up with Will Schroeder (@harmj0y) and
Mike Wright (@themightyshiv)
● We had separate tools, so we combined code
bases
● @Harmj0y didn’t sleep and combined the code
○ Took this as an opportunity to learn
framework development

28. Veil 2.0

29. Veil 2.0
● Fully modular framework
○ Drag and drop payloads
● “Language agnostic”
○ implement additional languages
● Easily Extensible
○ common libraries/methods available
● Huge UI focus
○ Tab completion, command line flags, etc.

30. The Veil-Framework
● We continued to come up with additional tools
which resulted in The Veil-Framework
○ “A toolset aiming to bridge the gap between
pen testing and red team toolsets.”
● Veil renamed to Veil-Evasion
○ Veil-Catapult - Initial payload delivery tool
○ Veil-Pillage - Post-Exploitation and payload
delivery

31. State of The Veil-Framework
● Still an actively maintained project
● V-Day
○ Victory over antivirus :)
○ Since 9/15/2013 we’ve released at least one
new payload on the 15th of every month
● Hoping for community involvement
○ hint hint… :)

33. Egress-Assess

34. Attackers don’t just target this...
http://2we26u4fam7n16rz3a44uhbe1bq2.wpengine.netdna-cdn.com/wp-
content/uploads/041514_1356_MurderingDe30.png

35. What’s the point?
● End Goal - Money/Data
○ Data - grab it, get it out
○ !disrupt
○ !deny
○ !degrade,
○ !destroy (maybe deceive)
○ Not just shells anymore

36. ...they target
this

37. Attacker C2 Comms

38. Tradecraft Evolution
● Pen Tests traditionally exploit vulnerabilities
○ Find and exploit vulnerabilities
○ Assess the security as a point in time
● Why not add in some exfiltration testing as
well?
○ Attackers DO this, why not help prep our customers?
○ Let’s emulate our threats

39. Our Solution

41. What does it do?
● Standard client/server model
● Simulates data exfiltration
○ Faux social security numbers or credit cards
○ And now real files :)
● Exfil data over multiple protocols

42. Project Goals
● Fast to set up for use
● Minimal (if any)
configurations
required to work
● Lightweight and no
excessive
dependencies
● Exfiltrate data over
different protocols
● Modular framework
that allows easy
expansion of
capabilities

43. Project Goals
● Store all data/files transferred for proof of
transfer
○ Stored in a specific directory
○ Time and date stamped for correlation with blue team
logs
● Demonstrate different options for data
exfiltration and educate the blue team

44. Tunneling Protocols

45. Supported Tunneling Protocols
● Protocols merged into Egress-Assess
● ICMP
● SMB
● DNS
● DNS_Resolved
● HTTP
● HTTPS
● FTP
● SFTP

46. FTP and SFTP
● Generates faux data and writes it to disk, or
transfers a file specified by user
● Creates FTP or SFTP connection to server and
transfers the file to the server
● If faux data is used, it deletes the file

47. FTP Transfer

48. ICMP
● Takes advantage of ICMP type 8 (echo)
○ Protocol allows you to specify the data used in
the echo request
● Splits data in 1100 byte chunks
● Base64 encodes data
● Uses encoded data for the echo

49. ICMP Transfer

50. DNS (Direct)
● Uses DNS TXT records
○ Max 255 bytes
● Split data into chunks, base64 encode each chunk,
send packets directly to Egress-Assess server
● Multiple limitations when working with DNS
○ Size restrictions, UDP, etc.
■ We’d say a joke, but you might not get it :)

51. DNS (Direct) Transfer

52. DNS Info
● Other protocol modules work well, but fail when a
proxy is used
● Other tools have shown that DNS can be used as a
communications channel
○ Cobalt Strike’s Beacon, dns tunnelling projects
(dnscat), etc.
○ Began researching different methods to exfil data via
DNS

53. Why Use DNS
● “But we don’t allow port 53 out!”
● Locked down environments can have proxies
● How many people inspect DNS?
○ How many people only resolve certain domains?
○ Can you block protocol compliant C2 comms or data
exfiltration attempts?
● Customer’s own DNS server FTW!

54. DNS (Resolved)
● Resolves local system’s nameserver
● Send request to system/network nameserver
○ <base64encodeddata>.subdomain.domain.com
● Server listens for incoming DNS A record request
○ Grabs record being requested, decodes it, and writes
data to disk

55. http://blog.cobaltstrike.com/2013/06/20/thatll-never-work-we-dont-allow-port-53-out/

56. DNS Resolved Setup
● Create DNS A record for your final destination
● Create NS Record for subdomain, point to A
record
https://www.christophertruncer.com/exfiltrate-data-via-dns-with-egress-
assess/

57. DNS (Direct) Transfer

58. More DNS Woes

59. https://docs.google.com/presentation/d/1HfXVJyXElzBshZ9SYNjBwJf_4MBaho6UcATTFwApfXw/preview?sle=true&slide=id.g2d0184395_097

60. https://docs.google.com/presentation/d/1HfXVJyXElzBshZ9SYNjBwJf_4MBaho6UcATTFwApfXw/preview?sle=true&slide=id.g34d85052a_
00

61. https://docs.google.com/presentation/d/1HfXVJyXElzBshZ9SYNjBwJf_4MBaho6UcATTFwApfXw/preview?sle=true&slide=id.g34d85052a_00

62. DNS Woes
● Leads to problems when transferring files
○ Faux data, don’t need to preserve order, or 100%
integrity
○ Binary files, this is a problem
● Currently working on essentially TCP over UDP
DNS transfers

63. Powershell all the things
● Same client modules as python client
● Simulate attackers from Windows systems
● Domain proxy support
● Deployable through Beacon, Meterpreter, etc..

64. Get-Help

65. HTTP Snort Capture

67. What I Wish I Knew

68. What I wish I knew
● Programming/Scripting
○ Start doing this
○ You can literally control a computer, and
make it do exactly what you want

69. What I wish I knew
● Programming
○ Get the theme? :)
● Mentor
○ You’re always one step in front and one step
behind someone
● Build a lab and play with it
○ You can’t break anything that costs money!

70. What I wish I knew
● Be prepared to be uncomfortable at times
○ Always in a new environment with new “stuff”
and you’re expected to break it
○ Perk of the job too :)
● Build your process
○ Learn how you best approach networks, web
apps, etc.
○ Use this to face what you don’t know

71. The difference between a new and
experienced hacker is the experienced hacker
can count on their problem solving ability to
navigate an unknown environment.

72. ?
● Chris Truncer
○ @ChrisTruncer
○ CTruncer@christophertruncer.com
○ https://www.christophertruncer.com
○ https://github.com/ChrisTruncer