O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Pen Testing Development

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 72 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (11)

Semelhante a Pen Testing Development (20)

Anúncio

Mais recentes (20)

Anúncio

Pen Testing Development

  1. 1. Pen Testing Devevelopment Christopher Truncer
  2. 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. 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. 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. 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. 6. When Coding...
  7. 7. Developing for Offensive Operations
  8. 8. 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
  9. 9. 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
  10. 10. EyeWitness
  11. 11. 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?
  12. 12. 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
  13. 13. Google!
  14. 14. StackOverflow
  15. 15. Proof of Concept
  16. 16. Make it Usable ● File Input ○ File, NMap, Nessus ● Web Timeouts ● Default Credential Checks ● Report Generation ○ Create Sections ■ High Value Targets ■ Error Section ■ etc.
  17. 17. EyeWitness Stats ● Originally: 409 Lines ● Now: 3402 Lines ● Reasons: ○ Login Signatures ○ Multi-Threading ● Guess for the real reason?
  18. 18. #avlol
  19. 19. 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
  20. 20. As Always, Ask the Google
  21. 21. 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...
  22. 22. Veil 1.0 - Released ● Small, single file script ● Limited payloads ● It worked… better than it really should
  23. 23. 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
  24. 24. 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
  25. 25. Veil 2.0
  26. 26. 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.
  27. 27. 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
  28. 28. 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… :)
  29. 29. Egress-Assess
  30. 30. Attackers don’t just target this... http://2we26u4fam7n16rz3a44uhbe1bq2.wpengine.netdna-cdn.com/wp- content/uploads/041514_1356_MurderingDe30.png
  31. 31. What’s the point? ● End Goal - Money/Data ○ Data - grab it, get it out ○ !disrupt ○ !deny ○ !degrade, ○ !destroy (maybe deceive) ○ Not just shells anymore
  32. 32. ...they target this
  33. 33. Attacker C2 Comms
  34. 34. 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
  35. 35. Our Solution
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. Tunneling Protocols
  40. 40. Supported Tunneling Protocols ● Protocols merged into Egress-Assess ● ICMP ● SMB ● DNS ● DNS_Resolved ● HTTP ● HTTPS ● FTP ● SFTP
  41. 41. 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
  42. 42. FTP Transfer
  43. 43. 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
  44. 44. ICMP Transfer
  45. 45. 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 :)
  46. 46. DNS (Direct) Transfer
  47. 47. 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
  48. 48. 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!
  49. 49. 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
  50. 50. http://blog.cobaltstrike.com/2013/06/20/thatll-never-work-we-dont-allow-port-53-out/
  51. 51. 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/
  52. 52. DNS (Direct) Transfer
  53. 53. More DNS Woes
  54. 54. https://docs.google.com/presentation/d/1HfXVJyXElzBshZ9SYNjBwJf_4MBaho6UcATTFwApfXw/preview?sle=true&slide=id.g2d0184395_097
  55. 55. https://docs.google.com/presentation/d/1HfXVJyXElzBshZ9SYNjBwJf_4MBaho6UcATTFwApfXw/preview?sle=true&slide=id.g34d85052a_ 00
  56. 56. https://docs.google.com/presentation/d/1HfXVJyXElzBshZ9SYNjBwJf_4MBaho6UcATTFwApfXw/preview?sle=true&slide=id.g34d85052a_00
  57. 57. 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
  58. 58. Powershell all the things ● Same client modules as python client ● Simulate attackers from Windows systems ● Domain proxy support ● Deployable through Beacon, Meterpreter, etc..
  59. 59. Get-Help
  60. 60. HTTP Snort Capture
  61. 61. What I Wish I Knew
  62. 62. What I wish I knew ● Programming/Scripting ○ Start doing this ○ You can literally control a computer, and make it do exactly what you want
  63. 63. 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!
  64. 64. 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
  65. 65. The difference between a new and experienced hacker is the experienced hacker can count on their problem solving ability to navigate an unknown environment.
  66. 66. ? ● Chris Truncer ○ @ChrisTruncer ○ CTruncer@christophertruncer.com ○ https://www.christophertruncer.com ○ https://github.com/ChrisTruncer

×