How to Annoy a Penetration Tester

1. How to Annoy a Penetration Tester Tech Talk Live 5/4/2016 Mark Lachniet marklac@cdw.com (847-968-0155)

2. About The Speaker • Information Security Solutions Manager, CDW (previously Security Engineer) • Presales and practice development • Penetration testing • Incident response & forensics • Regulatory compliance (HIPAA, PCI, NIST 800-53) • Past employment: • K-12 Technology Director (Holt Schools, MI, ~4k students) • Instructor, Masters in Information Assurance, Walsh College • Consulting at Analysts International, Promethean Security • Industry certifications: • Certified Information Systems Security Professional (CISSP) • Certified Information Systems Auditor (CISA) • Licensed Private Investigator #3701-205679 (Michigan) | Security solutions

3. About The Speaker • My one claim to K-12 fame: • 1997 Linux Journal #41 • Replaced 56k with WLAN • 1-4 mile hops • Installed Linux firewalls • Squid proxy server • “naughty filter” | Security solutions

4. Agenda • Quick review of security trends in K-12 – Verizon DBR • Discuss the differences between vulnerability assessments and penetration testing • Discuss the ways that I have been most successful in: • Getting access to a network • Getting a password • Escalating this access to administrator • Escalating this access to diverse systems • Discuss internal controls that would stop me • Question and Answers • No sales pitch! | Security solutions

5. The 2015 Verizon Data Breach Report • A fair number of incidents logged in the “education” category – seems to include Higher Ed • Seems to be a limited amount of investigation? | Security solutions

6. The 2015 Verizon Data Breach Report • Looked at reported incidents (i.e. self-reported) • Analyzed % of “Scope Unknown” removed < 50 • Is this because they don’t want to say how big the incident was or don’t know? | Security solutions

7. The 2015 Verizon Data Breach Report • Looked at confirmed data losses (i.e. public disclosures) • Analyzed % of “Scope Unknown” removed < 50 • By my math, about 2/3rds of incidents in education were not investigated deeply enough to know what was affected (or they weren’t saying) | Security solutions

8. Malware Events Per Week (5 industries) • Other Industries: | Security solutions

9. Malware Events Per Week (5 analyzed) • Education: Ouch! • K-12 Issues: • Too much stuff? • Too much diversity? • Too little trained staff? • A captive audience of attackers? • An “image and forget” model? • Perception of not being worth hacking? • Shared systems – the tragedy of the commons? | Security solutions

10. Time to Remediation – Other Industries • How long did it take, by industry, to stop malware once it was established? • Identified by malware command and control beacons | Security solutions

11. Time to Remediation – Education • Education has the worst record of those analyzed • Chances are, it took around a month or more for malware to be discovered and eradicated • Many non-managed systems • Risky use cases: • Home use laptops • Video games • Sketchy websites • Social media • Etc. • Clearly a problem with visibility | Security solutions

12. Types of “Bad Stuff” • When a root cause was found, education had the most in Crimeware and Errors, plus some theft | Security solutions

13. Opportunistic Attacks vs. Hacking • The biggest risk to K12 schools, by far, is opportunistic hacking rather than targeted hacking like a pentest • For example, malware distributed through e-mail attachments and web sites, rather than overt attacks • In an opportunistic attack, it doesn’t matter who you are or what you do, just how much money they can extort • Possibly the very best thing you can do for these types of attacks is to have good backups! • Targeted attacks are still a problem, however: • Motivated attackers (i.e. students) wanting to experiment, prove they can “beat the system” • Attackers with time to spare (i.e. students) • Attackers trying to prove they are cool (i.e. students) | Security solutions

14. Pen-Testing vs. Vulnerability Assessment • It is useful to differentiate between the two because there is a lot of confusion • Situation is aggravated by vendors that claim to be doing penetration tests when they really are not • Vulnerability assessment: • Primarily scanning for vulnerabilities using Nessus • Mainly meant to create an inventory of systems and vulnerabilities • Rank vulnerabilities by importance and cost • Minimal hands-on time and skill required, less $$ • House metaphor: “check all the doors and windows” • Vulnerability assessments are good when on a budget, or when needing “auditor kryptonite” • Finds unpatched systems but not real-world risks | Security solutions

15. Pen-Testing vs. Vulnerability Assessment • Penetration testing: • Proof that you can compromise systems, usually in several different ways • Show how compromises can spread across devices and systems, result in much bigger incidents • Use creative or intuitive thinking to find connections and ways to attack and escalate that aren’t immediate obvious • Requires hands-on knowledge of a lot of different technologies (Microsoft, UNIX, switches, firewalls, etc.) • Requires much more knowledge and time, thus more $$ • Very high success rate (> 95% for us when internal) • Give you an idea of potential SCOPE of a compromise • House metaphor: “go through the window and shave the dog, then go back outside and then in through the front door to drink your beer” | Security solutions

16. Getting In From the Outside • On the Internet, hacking “stuff” is easy but hacking a specific target can be hard • Most organizations have decent firewall rules and keep their Internet-facing servers patched • If you have unpatched Internet-facing systems you will probably discover this fact fairly quickly (the hard way) • Primary means of attack over the Internet in order of preference: • Social engineering / Phishing • Password guessing • Manipulation of server interfaces (i.e. Tomcat) • Known, attackable missing patches (i.e. Metasploit) • Attacks on applications (SQL injection, etc.) | Security solutions

17. Social Engineering and Phishing • Attacking an organization through phishing is FAR easier than attacking it through technical means • Many people are vulnerable to phishing, especially those who have not been using computers their whole lives • Humans have an in-built desire to be helpful, and attackers take advantage of this (and will continue to do so at an increasing rate) • The first step is to do discovery using public records: • Social media (LinkedIn, Facebook, etc.,) • Scripts and software to enumerate names and e-mail addresses from search engines • Look for user phone / email directories on official web sites | Security solutions

18. Phishing – How I do it • Identify generic inboxes such as marketing, accounts payable, IT helpdesk, etc. • Metadata from word and PDF documents – shows actual usernames and software packages used • Connect to webmail or SMTP and run census data against it to identify valid usernames • The goal of discovery is a list of valid user IDs / emails • Free Tool: FOCA • https://www.elevenpaths.com/labstools/foca/index.html • Free Tool: Maletego • https://www.paterva.com/web6/products/maltego.php • Controls: User ID’s that are NOT the same as email addresses and are not easy to discover (i.e. through metadata). Blocking repeat connections to mail services. | Security solutions

19. Phishing – Enticement • Focus on: Management, billing, HR • Avoid: IT, Risk Management, legal • Create customized phishing emails: • Must look legit – steal HTML signature block • Use timely information about the organization (time to re-up your insurance, student count day, etc.) • “bypass your organization’s firewall and content filter” • Contests - Amazon gift card for participating in a survey • Infected PDF documents – tracking from UPS or a vendor invoice that looks just legit enough to open • Free iPad! (who falls for this any more!?!) • Request from IT staff to test new and better system | Security solutions

20. Phishing Example – The Citrix Server • Create a fake Citrix web site registered under a name such as http://www.organization-beta.com that looks exactly like the official Citrix server (costs about $15) • Send a phishing e-mail saying that IT is responding to user demand and rolling out a new, much faster, Citrix server and that they have been selected to test it. Fake the IT director as the source with a perfectly copied signature at the end • The e-mail is from the lookalike domain, so any responses go to the attacker and not the IT director • The fake web site will take their login information (user ID and password) and log it to a text file. After submitting their login, they get redirected to the real Citrix server login page • User believes that they must have made a mistake typing in their password and often doesn’t notice the URL change • Possibly take 3-4 logins before redirecting – the users will type in every password they know which is useful to the attacker | Security solutions

21. Passwords Guessing • If we can’t get a user ID and password through phishing we can start making some educated guesses • Password1 (and 01, 2, and 3 and Password! – matches complexity, just increment numbers or try some common punctuation like ! or ?) and School1 • Changeme!, letmein!, and other “starter” passwords • Summer2016, Summer16! (password changes are usually quarterly, so you’ll often see Summer, Fall, Winter, Spring followed by the year in 4-number or 2-number format) • P@ssw0rd (the ‘ole leet speak vowel substitution trick, pick your favorite word or sports team and swap out some vowels) • Shared / service accounts (i.e. HR) with pass = user • Given a sufficiently large user base, someone usually has a password like the above • Controls: User training, check service accounts, no seasons, different starter passwords for each user | Security solutions

22. Attacks on Applications • Look for interfaces to middleware and control panels • Sometimes can find control panels for SQL databases • Tomcat, JBOSS jmxconsole, – often left with a default password, can be used to upload a “WAR” file to get a command shell on the server • Web application security attacks: • Time consuming and expensive • Test all client-side fields for proper input validation • May be able to find SQL injection attacks – if you can find one you can dump database contents (often including passwords) and even run commands (via xp_cmdshell) • See OWASP.ORG for more information • Controls: Make sure all management ports are firewalled, all interfaces have unique passwords, test web applications for security (even if off the shelf!), require proof of third party tests from vendors | Security solutions

23. Attacks on the Inside Network – Getting On • Need to be able to connect to the inside network • At schools this usually just means plugging in to ethernet • Plug into the pass-through port on an IP phone • Move a printer to a small hub/wireless router • Unmonitored but connected ports – band room, lounges, library • May be able to do it remotely or from guest wireless via VPN, VDI, Remote Desktop systems with a password • Guess the wireless password • Crack a wireless password (with WPA/WPA2 pre-shared keys it is possible to capture a few packets and then use wordlists or brute force attacks to identify the PSK) • Controls: Disable pass-through ports on phones, keep ports unplugged until needed, use Network Access Control systems, limit # of MAC addresses per physical port on switch, make WPA passwords long and not just a simple word/number combo | Security solutions

24. Internal Attacks – Getting Started • Once on the inside the first thing that will happen is to discover the network ranges in use • Use Wireshark to sniff the network and identify IP addresses and server names, DHCP leases • Sniff switch traffic such as the Cisco Discovery Protocol (CDP) protocol • Use NMAP ping sweeps to find live machines • Use Nessus to scan live machines for known vulnerabilities • Controls: Use very large 10.x.x.x/16 networks making it time consuming to find where the machines are. Use intrusion detection systems to alert you when scanning is taking place, use network segmentation to limit traffic between networks (for example, a client/printer VLAN usually doesn’t need to talk to another client/printer VLAN) | Security solutions

25. Internal Attacks – AD Account Checking • Assuming that you can’t identify systems that are vulnerable to attacks using known exploits and go directly to an exploit, you want to check Active Directory for easy passwords • Some server configurations will let you enumerate all of the domain’s user ID’s without authenticating, but this is more rare on modern systems, so you will usually need an account • Your first task as an attacker is to get at least one valid user ID and password, preferably for a somewhat privileged user • This may be as simple as getting a login that is used for a library system or a computer-on-wheels as a starting point, or even a student ID • Use the low-privilege account to list all user ID’s in AD • Check each user ID for passwords=blank, same as user ID, or 1-2 simple passwords (often works for service accounts) • Controls: No generic accounts, even if they have minimal rights. make sure servers require auth to list domain accounts, make sure all accounts have a password that is not blank or equal to the user ID | Security solutions

26. Fake AP Wireless Attacks • Can use the “fake AP” wireless attack • Many Windows systems remember AP’s they have connected to and constantly broadcast looking for them • The Fake AP sees these broadcasts and impersonates a previous AP such as a coffee shop so the client will connect to it (only works for open access points, not WPA, etc.) • Once connected, the attacker can view traffic to get passwords (if unencrypted HTTP, Telnet, etc) • Use a look-alike “captive portal” to get user to put in password • Can also manipulate what is seen by spoofing traffic • Fake AP attacks can also be useful to get onto Ethernet as many machines allow both to be connected at once • Controls: Don’t let Windows “remember” previous access points, be on the lookout for “rogue APs”, keep wireless disabled | Security solutions

27. Attacking Name Resolution: Responder.py • If you can’t get that first user ID, you can attack systems with misconfigured name resolution systems • Responder.py is demonstrative of this attack: • Issue occurs when machines are not properly configured to the local name resolution system (DNS) • Windows tries to resolve names like SERVER1 or cnn.com • If the machine cannot resolve the name using DNS, it resorts to LLMNR and NetBIOS which are *broadcast* on the local network • Any machine that sees the broadcast may respond that it is them, and hence get the machine to connect to them and the malicious processes they are running (like Responder.py) • Common for IT people who like to set up their own machines, since they are too cool to accept restrictive group policy | Security solutions

28. Attacking with Responder.py • Works especially well for systems that are not domain joined machines, such as those owned by staff and students • The best attack is to pretend to be WPAD.organization.org and serve up a proxy-auto-config (PAC) file • The PAC file list the attacker as being the proxy to use for Internet browsing, hence we can Man-In-The-Middle all traffic • Responder lets us do things like pop up authentication windows in order to access web servers, log user ID’s and passwords, and even modify HTML on the fly to inject executables, etc. • Controls: Make sure that you have a WPAD server defined in the correct DNS system so that machines don’t resort to insecure name resolution, ensure that DNS is properly configured – especially for domain joined systems and in DHCP leases, don’t let machines that aren’t properly configured on secure networks | Security solutions

29. Attacking with Responder.py • Example: the WPAD server (from my log files) LLMNR poisoned answer sent to this IP: 172.16.12.34. The requested name was : OFFICECUBES-015. LLMNR poisoned answer sent to this IP: 172.16.12.34. The requested name was : wpad. [+]WPAD (no auth) file sent to: 172.16.12.34 LLMNR poisoned answer sent to this IP: 172.16.12.34. The requested name was : isaproxysrv.. Client IP is: 172.16.12.34 LLMNR poisoned answer sent to this IP: 172.16.12.34. The requested name was : cnn Requested URL: http://www.bing.com/search?q=cnn&src=IE-TopResult&FORM=IE10TR Complete Cookie: _FS=mkt=en-US&NU=1; _SS=SID=D4BDAC3EFAA0459AA61EE66D4C33B36C; MUID=24A89A3984E36E6E24F79C4685FC6E88; OrigMUID=24A89A3984E36E6E24F79C4685FC6E88%2c367b40a8a956494fb9d5b3a227458330; SRCHD=D=3448476&MS=3448476&AF=IE10SS; SRCHUSR=AUTOREDIR=0&GEOVAR=&DOB=20140722 Client IP is: 172.16.12.34 | Security solutions

30. Windows Server Name Resolution Attacks • From the inside, plugged into your network (or your wireless) we have other tricks like the sticky samba: • To do this, use a customized version of SAMBA (a Windows fileshare emulator) that is configured for this purpose • See: http://www.foofus.net/~jmk/passhash.html for patches, or use Metasploit • The SAMBA server will automatically respond to all broadcast requests for a Windows file share by clients on the network and hold up its electronic hand saying “Oh! Oh! That’s me!” (just like Responder.py) • When the client connects, we get their password hash and can then crack it • Does tend to cause a lot of tech support calls for internal staff, as every single Windows request on that “broadcast domain” can go to our server and fail • Controls: Same as Responder.py | Security solutions

31. Internal Penetration and Pivoting • Once I get a user ID and password, I start looking to see what this account will get me into – usually this is a large chunk of workstations (if not all workstations, if not all windows systems, if not all systems) • Scan all Windows machines with Medusa to see if I can log in. If I can, I can browse around the machine (as is the case when “Domain Users” is added as a user group to domain members) • If I have local administrator access (“Domain Users” is added as a member of local administrators) we dump the local password hashes and session tokens • This allows me to get the credentials of every user that has a password cached on the machine, or that has a local account (often a service account or domain admin) • I then use THOSE accounts to scan each machine in the environment and repeat the process, until I finally find a cached credential for a domain administrator | Security solutions

32. Internal Penetration and Pivoting • Then I crack that hash and use it to pull data from a domain controller for analysis using volume shadow copy to get NTDS.DIT (the database of user Active Directory) • Once we have pulled the passwords from the domain controller, we run them through a password cracker in order to create statistics on how long it takes to crack the passwords • Compare the “average” organization with target for time to crack • Identifies the most common passwords and where in use • Useful for identifying very bad passwords very quickly, often these are used to get into yet more systems • In a penetration tests, these passwords are not used only on Windows machines but on SQL databases, network devices, appliances, physical security systems, etc. • Find exceptions to the password complexity rules • Often find leftover account provisioning passwords (changeme) | Security solutions

33. Example Trust Relationship Compromise | Security solutions

34. Internal Penetration and Pivoting • Controls: • Don’t allow local administrator rights for users • Add individual domain user accounts as local machine users, not “Domain Users” • Don’t use the same local administrator password in more than one place (painful!). • Don’t use the same admin password for more than one type of system (i.e. AD and Cisco and SQL) • Don’t log on to workstations with domain admin accounts unless absolutely necessary. • Enable workstation firewalls and network segmentation so I can’t connect and pull the data in the first place. • Have an alarm set so you get a text or email every time a new domain admin is made. Use IPS / SEIM to detect password guessing attacks | Security solutions

35. SYSVOL Groups.XML • Many networks have XML files containing poorly encrypted passwords on their SYSVOL directories due to use of Group Policy Preferences • Examples: groups.xml, printers.xml, and drives.xml • Created when manipulating local users, etc. on domain controllers (Windows 2008) • Passwords are stored in these in an easily breakable format, cracking tools are readily available • See: https://www.securestate.com/blog/2012/09/13/how-to-pwn-systems-through-group-policy-preferences • Frequently find scripts to join domains, etc. on SYSVOL and they sometimes have passwords hard-coded into them • Controls: Look for *.xml, .bat, .vbs, etc. on your SYSVOL (and other locations) and delete them. Don’t hard code passwords. | Security solutions

36. Random Passwords, Random Places • Another common mistake of organizations is a failure to accurately identify their sensitive information and appropriately handle it from “cradle to grave” • Once I get a domain user account password (or preferably domain admin account) one of the first things I do is connect to the organization’s various file shares and search for all files containing the word ‘password’ in them • Inevitably, I will find passwords for various internal systems, scripts and batch files that get run automatically, passwords used for testing, passwords for vendors or service accounts, text files or spreadsheets with users’ personal passwords to gmail and such • Approximately 50% of the time I can find a password for the organization, about 25% of the time it is an admin password. • Often allows escalation (to banking, DNS/SSL providers, etc.) • Controls: Log in as admin, do a keyword search for all files containing the word password. Weep. | Security solutions

37. Messing with IT Administrators • IT Admin workstations are useful to hack! • Install a key logger and then complain about the firewall • Look for device configuration backup files (especially Cisco routers and switches that use the easily decrypted “password type 7” format) • Look for cached passwords in programs like PuTTY or WinSCP. We may not be able to reveal the password but we can often change the IP address and change it from SCP to Telnet, then sniff the traffic as it connects to our system to get password • If networks are segmented so that only IT admins can connect to switches and infrastructure devices, then set up a proxy through their system to get to things you normally couldn’t • Review documentation, work notes, etc. for passwords • Controls: Make IT admin workstations AT LEAST as secure, don’t store backups with passwords in them, don’t cache passwords in software (use a password safe) | Security solutions

38. VNC Servers / Open Consoles • VNC sometimes has no password at all • Some VNC servers store passwords in the registry in an easily cracked way, this VNC password usually works on more than one system, so can escalate from one system to another • Tip: On the Internet, can look for these on your own networks using Shodan.io • Virtualization platforms like vSphere are often AD integrated. Log in and then look at the consoles of all of the running VM’s. If any of them aren’t locked, get on the console and make users, dump password hashes, look for passwords, escalate, etc. • Programs like HP Insight Manager and Dell DRAC are fun too – sometimes AD integrated, sometimes standalone passwords (root/calvinfor DRAC) • Citrix / Kiosk systems interesting because you can usually escape from the “lockdown” to get access to the underlying OS (which has a lot of interesting stuff) | Security solutions

39. Connect to Everything! • Make a list of all the Telnet, SQL, FTP, web interfaces, etc. found during port and Nessus scanning • Connect to each of them and find out what they are for – a good way to find interesting services on random ports • Research product on Internet – what is the default password? Try it! • This has gotten us into countless APC power devices, video surveillance systems, SAN/NAS devices, etc. • Multi-Function Printing (MFP) devices are especially interesting if they have a LDAP connection to AD for scan to home folder functionality – have found many devices with default printer credentials but with configured LDAP credentials that we could steal to get domain access • SQL databases are also interesting, often have no or stupid passwords – users often don’t even know they are there | Security solutions

40. Connect to Everything! • Connect as anonymous (or with discovered credential) to FTP, NFS, and open Windows shares to see what is in there • People often share out their entire C$ accidentally • NAS systems often have wide-open shares as well • Often find sensitive information like SSN from batch processing import/ jobs • Be on the lookout for SQL->plain text dumps being used as a backup system (saves on SQL backup agent costs) • Often find ghost images, virtual machine images, or backup files. Copy them, then extract the password hashes from them • Log into mail systems using discovered passwords and search all mail items for phrase “password” • Controls: Poke everything you can poke, think like a villain | Security solutions

41. Border Security • Most organizations are pretty good about blocking incoming traffic from the Internet and DMZ • K-12 is also usually okay about outgoing (egress) traffic to some degree and will typically block HTTP/HTTPS unless it goes through a proxy or filter • However, this is not enough – must block ALL outgoing ports except those that are necessary for functionality • Example: Kid uses Remote Desktop to control a home computer to browse from there • Even that isn’t really good enough because most malware now uses HTTPS – use (at a minimum) one that blocks to known malware IP’s or (better) inspects HTTPS traffic) • Obviously, have a proper DMZ • Controls: Default deny-all, allow only what needed | Security solutions

42. Logging and Incident Response • Many organizations do not have formal oversight of information security (i.e. a group that meets regularly to talk about security risks, track findings and tasks, etc.) • Most organizations do not have a good logging system, let alone a way to use log data proactively to identify abuse • While some organizations do have an incident response plan, many don’t and those that do have one that isn’t terribly good • The most effective way to catch a hacker is a combination of technology (logging systems) and human oversight (someone to tune and monitor systems) • Consider the following Hierarchy of logging – each level assumes all of the levels below it | Security solutions

43. Lachniet’s Hierarchy of Logging | Security solutions

44. Logging and Incident Response • Even basic logging, providing it is stored off-device and includes minimal information such as IP addresses, ports, administrative actions, etc. is better than nothing • Can then be used in the event that you have a particularly nasty incident that involves fraud, pornography, etc. • Example: Simply getting an email any time a user is added to “Domain Admins” or “Enterprise Admins” • Example: Getting a list of all new user adds and having helpdesk staff tie these back to a specific ticket so they can see if they are all legitimate • Example: Logins to Internet-facing systems (from other countries, from multiple simultaneous locations, during odd hours when they should be sleeping or on-site, etc.) | Security solutions

45. Training and Testing • You can never get too much training • K-12 has in-service days – you may be competing for limited time but at least you have a venue • Consider using LMS system and make sure that all users with above-student privileges take it • Send your IT people to decent training • Use real-world phishing exercises to make the point • Scan your own stuff, swap scanning with another district • Periodically contract real red team / penetration tests (try to make sure they don’t suck first) • Get practice and procedure reviews to help prioritize funding and prioritize over multiple years | Security solutions

46. Incident Response: Higher Ed & K12 • Received a call from a college in Michigan that they had an issue with malware on their workstations and wanted help investigating it in 2012 • Had identified a possible suspect based on log entries and wanted verification • Student was using a laptop and flash drive that were university property • At the time I was engaged, the student still had his laptop and was attending class • I verified the log entries and agreed on their identification of the individual • Advised them on seizing potential evidence and some forensic best practices | Security solutions

47. Incident Response: Higher Ed & K12 • At that time they went to the student while he was in class and took his laptop and flash drive from him • Made a copy of his data to a new flash drive so he could retain his work while he looked on • Student was visibly nervous, and tried to “move” his data rather than “copy” his data from the laptop and flash drive • Began a forensic analysis on flash drive and several machines • College interviewed student another time and he admitted to the hacking but stated that there was no “key loggers” to get passwords • I sat in an interview and asked technical questions about how it was done | Security solutions

48. Incident Response: Higher Ed & K12 • Student admitted to writing his own malware, used Metasploit to attack other machines that were college issued • This was possible because the administrator password on all college laptops was the same • Used a “pass the hash” attack to distribute the malware • Went undetected for months until he made a mistake with a document showing up on desktop • Also used a home computer to receive the results of the malware, shared on dropbox • Law enforcement was involved • Student agreed to bring in his home computer for analysis (this turned out to be a mistake on his part) | Security solutions

49. Incident Response: Higher Ed & K12 • Performed additional forensic analysis and found hacking evidence not only of the college but also of his K12 school (he had graduated 2 years previously) and other wireless networks • Involved the K12 school • Also discovered what I believed to be child pornography • The pornography was also found in the “swap” virtual memory file, indicating that it had recently been accessed • Created a report of findings, versions of which were provided to the K12, College and law enforcement • At this point went into the void of law enforcement • In late 2013 got a request from law enforcement to resend report, 2014 learned prosecutor wasn’t going to charge | Security solutions

50. Q&A / Discussion ???? Thank You! | Security solutions