![Recommendations
• Be proactive
• Use third-party threat intelligence feeds to identify compromised hosts in your environment
• Trust (believable) abuse complaint reports
• Scrutinize hosts that receive a large amount of abuse complaints
• Ignore reports that come from people who complain when the receive a single port scan
• Start with strict firewall controls
• Deny any inbound traffic beyond what is necessary and force the user to whitelist additional
services
• Consider vulnerability scanning your own environment and relaying concerning
results to your customers
• Google and Vultr do this
• [SHAMELESS SELF PLUG] Ask me about the GreyNoise Cloud Trust Alliance
program](https://image.slidesharecdn.com/usinggreynoisetoquantifyresponsetimeofcloudproviderabuseteams-190204085117/85/Using-GreyNoise-to-Quantify-Response-Time-of-Cloud-Provider-Abuse-Teams-34-320.jpg)
Using GreyNoise to Quantify Response Time of Cloud Provider Abuse Teams
- 1. Using GreyNoise to Quantify Response Time of Cloud Provider Abuse Teams Andrew Morris @andrew___morris [email protected]
- 2. • Thank you ACoD! • Founders • Committee • Staff • Attendees
- 3. About Me Andrew Morris Founder, interim CEO @ GreyNoise Intelligence Previously: - Endgame R&D - Intrepidus (NCC Group) - KCG (ManTech) Twitter: @andrew___morris Email: [email protected]
- 4. Agenda • What is GreyNoise • Background • Research Questions • Qualifiers • Methodologies 1-4 • Results • Recommendations
- 5. About GreyNoise GreyNoise is a gigantic system of globally-distributed passive collector sensors that monitor, analyze, and contextualize Internet-wide background scan and attack traffic. GreyNoise processes tens of millions of packets from hundreds of thousands of IPs every day Security professionals use GreyNoise to filter noisy alerts, identify compromised devices, and observe emerging threats. Learn more at https://greynoise.io or explore the data at https://viz.greynoise.io/
- 6. GreyNoise Examples (benign) • Cliqz • ShadowServer.org • Riddler.io • BinaryEdge.io • FindMalware • Quadmetrics.com • Stretchoid.com • CCBot • Internet Census • Stanford University • Brown University • CheckMarkNetwork • Mojeek • Cambridge Cybercrime Centre • Moz DotBot • Net Systems Research • Uptime.com • PDRLabs.net • Ruhr-Universitat Bochum • MJ12bot • A10 Networks • Baidu Spider • CompanyBook • Sogou • PingZapper • ipip.net • CyberGreen • Qwant • ExposureMonitoring • IBM oBot • University of Michigan • Team Cymru • Panscient • MauiBot • Facebook NetProbe • Archive.org • RWTH AACHEN University • Shodan.io • SiteExplorer • Kudelski Security • Project Sonar • SEMrush • ProbeTheNet.com • University of California Berkeley • Project25499 • Intrinsec • LoSec • DomainCrawler • BingBot • GoogleBot • DataProvider • Yandex Search Engine • Statastico • Censys • Cloud System Networks • DomainTools • Mail.RU • Talaia • Ampere Innotech • aiHit • ONYPHE • Ahrefs • OpenLinkProfiler • NetCraft • University of New Mexico • Seznam • Coc Coc • SafeDNS • Pingdom.com
- 7. GreyNoise Examples (malicious) • Eir D1000 Router Worm • D-Link 850L Worm • MSSQL Bruteforcer • Realtek Miniigd UPnP Worm CVE-2014-8361 • ZmEu Worm • Telnet Worm • Jboss Worm • D-Link 2750B Worm • PHP Worm • Apache Struts CVE-2017-5638 Worm • Mailbox Bruteforcer • Looks Like RDP Worm • Belkin N750 Worm CVE-2014-1635 • D-Link DSL-2640U DNS Hijack Vulnerability • EquationGroup Eternal/MS17-010 • Compromised Raspberry Pi • Oracle WebLogic CVE-2017-10271 Worm • HTTP PUT Uploader • Looks Like Conficker • Generic Windows Worm • Open Proxy Scanner • ADB Worm • Eternal MS17-010 • PHP InvokeFunction Attacker • IIS WebDAV Remote Code Execution CVE- 2017-7269 • Mikrotik CVE-2018-14847 Worm • Windows RDP Cookie Hijacker CVE-2014- 6318 • Zyxel OS Command Injection CVE-2017-6884 • VNC Bruteforcer • CHINANET SSH Bruteforcer • SSH Worm • PHPMyAdmin Worm • Wordpress Worm • Huawei HG532 UPnP Worm CVE-2017-17215 • Wordpress XML RPC Worm • Postgres Bruteforcer • Avtech IP Camera Worm • Hadoop Yarn Worm • Unknown Linux Worm • FTP Bruteforcer • GPON CVE-2018-10561 Router Worm • Mirai • Looks Like EternalBlue • Embedded Device Worm • D3c3mb3r Botnet • Linksys E-Series TheMoon Router Worm • Unauthenticated Redis Worm • Drupal CVE-2018-7600 Worm • CGI Script Scanner • LINK-NET LW-N605R Worm CVE-2018-16752 • Asterisk Bruteforcer • Apache Struts CVE-2018-11776 Worm
- 8. Background • There are many compromised devices around the Internet • A subset of these compromised devices become infected by exposing vulnerable services directly to the rest of the Internet • These services can be configured to accept default/easily guessable credentials or they can be unpatched and vulnerable to a large series of remote exploits • Botnets and bad guys constantly scan and crawl the Internet to find and infect these hosts with unsophisticated malware • Once infected, many of these compromised devices spread their malware to other hosts by opportunistically scanning for and attacking other similarly vulnerable devices around the Internet • This kind of activity is executed by a specific sub-category of botnet (Mirai, Satori, Muhstik, etc) • Most of the attacks an organization sees to the network perimeter originate from these devices
- 9. Background (cont’d) • When a device becomes compromised inside of a cloud provider (such as AWS, Google Cloud, DigitalOcean, etc) it will often start to attack other hosts around the Internet • The cloud provider abuse contact will start to receive some signals that the devices is compromised: • Abuse complaint emails from other network administrators around the Internet • A large uptick in traffic to thousands or millions of destination IPs over protocols that are generally used by authentication (SSH, Telnet, etc) • Some period of time after the device is infected / attacking other servers around the Internet (without being remediated by the owner), the cloud hosting provider abuse team will decommission or quarantine the server
- 10. Research Questions 1. How much time generally passes between a device in a cloud provider starting to attack other hosts around the Internet and for the activity to be remediated? 2. How much variance is there between different cloud hosting providers, such as Amazon AWS, Microsoft Azure, Google Cloud, DigitalOcean, etc? 3. How much variance is there internally on a given cloud hosting provider? 4. How many compromised devices are there in each cloud hosting provider?** 5. How long have is the longest “total compromised host time” of each provider? - …using compromised device data collected and labeled by GreyNoise ** This is a Dumb Question™️
- 11. Goal • Walk away with an understanding of how different cloud providers handle compromised devices within their network • Walk away with an understanding of how to reproduce this research with your own data sources • Walk away with an understanding of GreyNoise
- 12. Using GreyNoise to Quantify Response Time of Cloud Provider Abuse Teams In other words…
- 13. Qualifiers SHAME • This talk is not intended to shame anyone or compare what organizations are “better” or “worse” • We are measuring “response time”, not “effectiveness” Work sucks • Security is hard enough without some asshole telling you how to do your job Trust / Abuse / Fraud is hard • SOC / trust / abuse / fraud teams are INSANELY overworked • It’s a hard and thankless job • I have an ENORMOUS amount of respect for the folks who work these jobs Grace period • Every cloud provider has different internal policies on how long to wait until decommissioning or quarantining a customer server, as to not disrupt their business
- 14. Qualifiers (cont’d) Collection Bias • There are many gaps in my methodology and it is by no means conclusive. This talk is one data point from one source Comparison • Cloud providers have different problems and different priorities than other hosting types (ISPs, corporate networks, telecommunications providers) Customer != Corporate • These devices are not located in any of these organization’s corporate networks CYA • This talk is in no way a reflection of these organization’s security posture. It is a set of observations based on a specific set of data.
- 15. Data sources • Infection status – GreyNoise • Cloud provider ranges – IPinfo.io • Cloud provider sizes – IPinfo.io • I love IPinfo.io with all of my heart
- 16. Subjects • Amazon AWS • Google Cloud • DigitalOcean • Microsoft Azure • Oracle Cloud • Rackspace • Linode • IBM Softlayer • Vultr • Tencent • Ali Cloud • OVH • SingleHop • CenturyLink
- 17. Methodology 1: Pure quantity** • How many unique compromised IPs are there inside a given cloud hosting provider? • Over a four (4) month sample • This is a really, really, really stupid way to gauge anything • This breaks down when “size” is taken into consideration • A larger cloud hosting provider will simply have more compromised devices • E.g. if Google Cloud has 100 compromised devices (out of ten million customer machines) that’s very little • If a small cloud hosting provider with 1024 IPs has 100 infected devices, that’s *really* bad • Recreate: $ gnql $org classification:malicious | jq '.count'
- 18. Methodology 1** (this is a bad metric)
- 19. Large ISPs for scale
- 20. • Amazon: 2176 • DigitalOcean: 5465 • Vultr: 1677 • Google: 900 • Microsoft Corporation: 837 • Oracle: 540 • Rackspace: 79 • Linode: 251 • Softlayer: 192 • Tencent: 4846 • Alibaba: 292 • OVH: 2310 • SingleHop: 27 • CenturyLink: 736 Compromised IPs observed by GreyNoise over a four (4) month sample
- 21. Methodology 2: Ham-fisted cumulative time** • What is the total time (in hours) between the time GreyNoise first and last saw all infected IPs in a given cloud hosting provider? • This is also a really, really bad way to measure anything • Breaks down when size is taken into consideration • Also breaks down when you take IP recycling into consideration • IP re-use between accounts • IP recycling between “known good” Internet scanners (Shodan, BinaryEdge) and briefly infected devices • Multiple infections on the same host over a long period of time (the “state” of “infectedness”)
- 22. Methodology 2** (this is a less bad metric but is still pretty bad)
- 23. Total time (in hours) between the time GreyNoise first and last saw all infected IPs in a given cloud hosting provider? • Amazon : 652.42 • DigitalOcean : 648.64 • Vultr : 1060.51 • Google : 447.66 • Microsoft Corporation : 490.80 • Oracle : 1991.11 • Rackspace : 2694.37 • Linode : 578.67 • Softlayer : 910 • Tencent : 1835.27 • Alibaba : 1186.23 • OVH : 2048.07 • SingleHop : 1265.77 • CenturyLink : 1139.16
- 24. Methodology 3: Cumulative “infected” time (adjusted) • How many cumulative “state of infected” hours (per 10,000 IPs) are there for a given cloud hosting provider? • Get all IPs that have ever been infected inside a given cloud provider • Use GreyNoise to find the exact time ranges they were infected • Account for time interval overlap (this was a lot harder than I thought it would be) • Add all of the hours together • Get total size of Cloud provider, in IPs (using IPinfo.io) • This is harder for some providers than others • This is also not accurate, but it’s better than nothing • Divide hours by total IPs/10,000 • This breaks down because it makes smaller, busier hosting providers look slower and positively biases gigantic hosting providers (by dividing their “hour” amount by a huge number)
- 28. Cumulative Compromised Hours / (Total IPs / 10,000) • Amazon : 174370 / 2945 = 59.20 • DigitalOcean : 1305470 / 55 = 23735.81 • Vultr : 199017 / 28 = 7107.75 • Google : 100252 / 243 = 412.55 • Microsoft Corporation : 131239 / 1302 = 100.79 • Rackspace : 18653 / 135 = 138.17 • Linode : 7598 / 26 = 292.23 • Softlayer : 14428 / 190 = 75.93 • Tencent : 1405329 / 26 = 54051.11 • Alibaba : 41859 / 20 = 9586.62 • OVH : 1342128 / 140 = 9586.62 • SingleHop : 2025 / 26 = 77.88
- 29. Methodology 4: Average time-to-close of an infected host • What is the average amount of time between a machine getting infected (and attacking other hosts) and the infection being remediated (no longer attacking other hosts) • Find and average intervals of time (in hours) between attacks starting and stopping • Problem: Just because the machine stops attacking other hosts does not mean it is no longer infected • This is equally evident to GreyNoise and the hosting provider itself
- 31. Average Time-To-Close (hours) • Amazon : 40.92 • DigitalOcean : 118.12 • Vultr : 51.63 • Google : 66.46 • Microsoft_Corporation : 82.74 • Oracle : 107.76 • Rackspace : 78.29 • Linode : 17.48 • Softlayer : 34.73 • Tencent : 95.58 • Alibaba : 31.04 • OVH : 232.29 • SingleHop : 28.16 • CenturyLink : 19.21
- 32. Bonus Metric • How many devices are compromised in each provider right now? $ gnql metadata.organization:whatever classification:malicious last_seen:>=2019-01-29 | jq .count
- 34. Recommendations • Be proactive • Use third-party threat intelligence feeds to identify compromised hosts in your environment • Trust (believable) abuse complaint reports • Scrutinize hosts that receive a large amount of abuse complaints • Ignore reports that come from people who complain when the receive a single port scan • Start with strict firewall controls • Deny any inbound traffic beyond what is necessary and force the user to whitelist additional services • Consider vulnerability scanning your own environment and relaying concerning results to your customers • Google and Vultr do this • [SHAMELESS SELF PLUG] Ask me about the GreyNoise Cloud Trust Alliance program
- 35. QUESTIONS?