Help and advice list
I compiled a list of -hopefully- useful tips and help for dealing with the WannaCry ransomware. I try to keep the page updated as soon as new information is available.
See https://www.wannacry.be/. Feedback is welcome!
What could have limited the impact of the WannaCry / Wcry / WannaCrypt ransomware?
The WannaCry / Wcry / WannaCrypt ransomware
A major wave of ransomware called WannaCry / Wcry / WannaCrypt has hit many organizations around the world, causing panic among many users, system administrators and security professionals. The details of the ransomware have been covered in detail at other posts
- Everything you need to know about the WannaCry / Wcry / WannaCrypt ransomware
- Player 3 Has Entered the Game: Say Hello to ‘WannaCry’
- Massive outbreak of ransomware variant infects large amounts of computers around the world
The massive impact of the ransomware was due to three primary factors
- This variant of ransomware posessess the capability to spread itself as a so-called worm
- It exploits a known vulnerability in Windows
- It uses a network protocol (SMB) that is often unfiltered inside corporate networks
The exploit abused a flaw in all versions of Windows that was patched by MS17-010 on 14th of March 2017. Windows 10 and Windows Server 2016 were protected in their default configuration. The flaw was located in SMB (ports 139, 445), a protocol used by Windows systems to communicate with file systems over a network. The exploit, also known as ETERNALBLUE and released earlier by Shadow Brokers, allows remote access with system privileges. This means an attacker can execute remote code at will, taking full control of the system. Additionally it was observed that the ransomware scans for the presence of DOUBLEPULSAR on other systems.
You can follow the activity of the malware via the Malwaretech bot tracker.
Note that the spreading of the ransomware was stopped by MalwareTech by registering a domain that was used internally in the malware.
Ransomware isn’t something new but we’ve not witnessed a ransomware wave on such large scale. What’s the reason why this flavor had such a large impact on companies around the world?
It’s the fault of the NSA!
The vulnerability that allowed the execution of this ransomware was known by the NSA for quite some time. This was disclosed by the Shadow Brokers leak in April. Sample exploit code was quickly available (and here) and put to use by attackers. The fact that the NSA (or any other agency – both government and private) uses these type of -until then unknown- vulnerabilities should not come as a surprise. It’s the way they run their surveillance business. It is reasonable safe to assume (but it does not justify the use) that the NSA used this vulnerable only against specific targets.
The fact that there was a vulnerability however meant that it was only a matter of time until another organization discovered the same flaw and benefited from it. In an perfect world the NSA should have informed Microsoft (‘responsible disclosure‘) so users would have been protected. Unfortunately, this isn’t the way things work. Remains the fact that the very same vulnerability that allowed surveillance by a (or more?) government agency now causes havoc for those same governments.
Quickly after the public disclosure of the bug Microsoft patched the vulnerability. Closing the hole for everyone. Right?
You should have patched!
Microsoft patched this vulnerability as part of MS17-010. The vulnerability was rated Critical. Windows systems that use Windows Update should have received this update during patch Tuesday. This works well for home users (provided they have enabled Windows Update!) however corporate environments are rarely going to deploy a patch without profound testing. In some cases a patch changes the way a system works, introducing the risk of breaking a business critical application. Therefore proper testing has to be done before deploying a patch to an entire organization. This can cause a lot of delay between the annoucement of the patch and the actual implementation of the patch, leaving a window of opportunity for attackers.
I can restore my files from backups!
You should have made backups!
If your documents are encrypted (or inaccessible due to some another malfunctioning) you can restore them from backups. Note that relying on shadow copies is not going to help in this case as the ransomware also targets these files (by using WMIC.exe, vssadmin.exe and cmd.exe).
Unfortunately a restore procedure takes precious time. Restoring backups isn’t something that happens immediately nor is it done by an automatic process. These things requires an intervention by your IT department and in the mean time people are unable to continue with their work. It also takes some time for your IT department to figure out what is going on.
Many corporate environments run backups, but not all of them have tested their restore procedures properly and had the opportunity to iron out the obstacles that prevent a swift recovery.
Some environments make backups via … SMB (copying files to a remote share or disk). This means that the file share (or in some cases, merely an external disk) used as a safe backup could have been crippled as well by the ransomware. Having encrypted backups is not going to help in recovering from this incident.
You should not have opened that file!
Awareness campaigns warn users of phishing attacks. These campaigns play a big role in preventing malware from being introduced to your network.
This type of ransomware however only needed one curious user on your network to open the file to cause havoc and spread to other systems. Awareness is certainly going to help in preventing a lot of maliciousness on your network but you can not control the behavior of everyone. Attackers know that you run awareness campaigns, so they try to make their phishing messages more enticing for users to open. Even security conscious users can be taken of-guard. It only takes one convincing e-mail or document to get by that line of defense. This also introduces the reason for having multiple lines of defense.
I have an up-to-date anti-virus!
An anti-virus application will only protect you against the known threats. Although most anti-virus vendors will have their signatures updated by now, this would not have prevented the initial attack when it was still unknown and under investigation. Once attackers change one bit in the malware, signatures will not help.
How can I prevent the impact of WannaCry / Wcry / WannaCrypt?
Patch!
Critical patches with known exploits should require immediate attention
Applying the MS17-010 patch would have prevented this incident. Corporate environments can not apply every patch immediately. This is understandable. In your patch policy your should however take into account that
- A patch rated as critical
- A vulnerability for which known exploits exist
should require immediate action. Whether you use a CVSS scoring mechanism or any other rating, knowing that there is a vulnerability that is easily exploitable in your environment should require immediate attention. It can be a struggle to request for sufficient resources to be assigned to having testing and deployment set as a priority. This incident however shows that by preventing the problem you can save on resources (be that human resources or financial consequences). In essence this has not have to do as much with ‘security’ but more with having good IT governance and applying good practices. Rapidly applying critical security patches should be part of your regular IT governance process.
Unsupported systems? Microsoft discontinued support (including security patches) for a number of products (like Windows XP) but provided some mitigation measures for these out-dated products.
Disable what is not needed – SMBv1!
Application whitelisting
Disable SMBv1
Application whitelisting is a must have but is often not always feasible in a corporate environment. Preventing execution in a random path, the one where the ransomware can execute, will limit the impact of most malware (not only WannaCry). This can be achieved via application whitelisting but also by system hardening.
For this particular incident, disabling SMBv1 would have prevented the malware from spreading further in your network. Disabling SMBv1 is described in a Microsoft document. There’s no real excuse for still using SMBv1 in your corporate environment.
Filter SMB connections
Limit SMB to systems that really need it
Most corporate environments will now filter SMB connections coming from the internet. In a lot of environments however internal SMB connections are allowed (do not forget the VPN!). You should reconsider this. Not all of your machines require incoming SMB (or RDP) connections. Most security suites now include a local host firewall. If you are not using a security suite you can use the build-in firewall of Microsoft. Deploy a policy that filters all SMB connections for machines and only allow authorized connections.
Disconnect your backups and test your restore procedures
Use a dedicated backup solution that is not using SMB!
Backups do not have to be run through the regular file sharing protocol. There are backup solutions available that are not subject to flaws inherent to the SMB protocol! If you do backups via SMB, make sure that the disk (or share) is only connected during the time of the backup!
Use ACLs and network segmentation!
Apply network segmentation and strong ACLs
Use network segmentation, with proper network filtering, and implement strict ACLs. Your corporate workstations do not have to be able to connect to every internal resource available via SMB!
Integrate threat intelligence to your security work flow
Implement detection rules based on community threat effort
The security community was very quick in recognizing this threat and issued a list of indicators and detection rules (including YARA rules). Threat intelligence will not patch the vulnerabilities that are out there but it will give you a very quick heads-up on what is going on, allowing you to implement detection measures and filtering rules. If you have not done so, contact CIRCL to subscribe to their MISP threat intelligence feed.
Block access to the ‘kill-switch’ domain on our firewall/proxy?
No you should not. When the malware is capable of reaching the ‘kill-switch’ domain it will not further spread the malware. Please note that when you block this domain, it will in fact continue spreading both internal and external.
I’m safe!
No you are not safe! Even if you have mitigated the effects of this particular strain of malware, it’s only a matter of time until miscreants alter the behavior or infection path. As long as you have not patched your systems for this particular vulnerability you will be at risk!
Note that patching this vulnerability will not remove the danger of ransomware. This flavor of ransomare uses a vulnerability that can be patched but there are other avenues that can be used by malware to cause havoc in your organization. The key to combat this danger is
- Patch your systems
- Log network, system and service events so that you know what is going on
- Limit functionality to what is only needed
- Limit user access
- Filter network access
- Use threat intelligence feeds for early awareness
- Have a tested backup and restore plan
- Repeat awareness campaigns
References
ipv6: Neighbour table overflow
One of my virtual machines hosted at Gandi had an excessive amount of error messages
localhost kernel: ipv6: Neighbour table overflow.
The cause of this error message are the IPv6 router announcements that try to discover and configure the IPv6 neighbourhood. The excessive amount of messages were polluting the logs.
After contacting the Gandi helpdesk they provided insight on the cause of the error message and provided mitigations to prevent these type of errors. I had to update /etc/sysctl.conf with these entries
# Force gc to clean-up quickly net.ipv4.neigh.default.gc_interval = 3600 net.ipv6.neigh.default.gc_interval = 3600 # Set ARP cache entry timeout net.ipv4.neigh.default.gc_stale_time = 3600 net.ipv6.neigh.default.gc_stale_time = 3600 # Setup DNS threshold for arp net.ipv4.neigh.default.gc_thresh3 = 8192 net.ipv4.neigh.default.gc_thresh2 = 4096 net.ipv4.neigh.default.gc_thresh1 = 2048 net.ipv6.neigh.default.gc_thresh3 = 8192 net.ipv6.neigh.default.gc_thresh2 = 4096 net.ipv6.neigh.default.gc_thresh1 = 2048
The configuration file sysctl.conf is a file containing the setting that reads and modifies the attributes of the system kernel.
After updating the configuration file, had to apply them with
sysctl -p
Changing the configuration file and applying the settings prevented these error messages from polluting the syslog messages.
The Apache Struts 2 Vulnerability and the Importance of Patch Management
I published an article on IBM Security Intelligence on The Apache Struts 2 Vulnerability and the Importance of Patch Management.
The post describes a vulnerability in Struts 2, a free, open source framework for creating Java web applications that allows attackers to execute arbitrary code.
Simplifying Risk Management
I published an article on IBM Security Intelligence on Simplifying Risk Management.
What is Shodan telling us about ICS in Belgium?
Shodan
I have been using Shodan, “the world’s first search engine for Internet-connected devices”, since a long time. Recently I switched my free account to a membership account. A membership account allows you to do API queries with additional query filters (for example restricting search results to specific countries).
In this post I describe the results of querying the Shodan API for ICS (or related) devices in Belgium. These results are entirely based on what is available via Shodan without touching any of the affected devices.
Searching for IoT, SCADA and other stuff.
The developer API allows you to query the dataset and then parse the results offline with your own tools. I wrote a Python script that queried Shodan for a number of interesting ICS/SCADA/IoT strings, parsed the results and then stored them in a sqlite database. These are the queries that I ran with Shodan
Building Operation Automation Server Schneider Electric moxa eWON Sauter scada 3S - Smart Honeywell rockwell title:'xzeres wind' html:'PIPS Technology ALPR Processors' port:502 port:102 port:20000 source address port:789 product:'Red Lion Controls' port:1962 PLC port:5094 hart-ip port:18245,18246 product:'general electric' port:1911,4911 product:Niagara port:47808 port:44818 port:9600 response code port:5006,5007 product mitsubishi port:2455 operating system port:20547 PLC port:2404 asdu address port:161 simatic port:3011 port:1911 mitsubishi siemens
Because I was only interested in the results from Belgium I limited the search to country:BE.
The logic of the script was
- Perform the search query with api.search(expr);
- For every host, retrieve the details (hostname, open ports) with api.host(ip_str, history=False);
- If the host was not previously seen in the database, insert it in a host table and keep track of the associated domain and hostname;
- Parse the details of the host
- Add every open port to the database, but only if the combination of host+port+transport isn’t already there;
- Extract useful product and device information;
- Do this with the information available via Shodan or by simple banner parsing.
In total there were 654 unique hostnames.
Shodan results
This is not a “state of ICS in Belgium” but a snapshot of the ICS/SCADA/IoT information for Belgium that is available in Shodan. This is publicly available information.
Most popular domains
The majority of the hosts were located on the networks of Belgacom, Mobistar, Telenet and Proximus. This is to be expected as these are the largest ISPs in Belgium. Belgacom and Proximus are the same provider and Mobistar is now Orange. Also note the domain ‘telenet-ops’, which is the “OPS”-network of Telenet, and the results for Infrax, a utility company for gas, electricity and cable television.
Open ports per host
The majority of the hosts only had one or two open ports. Note that there are a lot of hosts that have 35 or more open ports.
Top 10 open ports
It is not a surprise to see that the most popular open ports are
- tcp/80 (http)
- tcp/8080 (most often http)
- tcp/443 (https)
Other ports that are returned as “open” are
- ModBus (tcp/502)
- Rockwell (tcp/44818)
- Moxa (tcp/4800)
- Niagara (tcp/1911)
Rockwell Automation, Moxa and Niagara provide ICS or IoT automation control systems. Typically these are the type of systems you do not want to be publicly available to the whole world.
Device type
The majority of the ports did not return a device type according to Shodan.
Vendor ID
Similar to the device type, the majority of the ports did not return a vendor ID according to Shodan.
Product name
I had to do some extra parsing for extracting the product names.
- Try the product name provided by Shodan
- If still empty, if it’s http, return the HTTP banner
- Or extract the first string that’s returned in the data object from Shodan
Despite extra parsing efforts a lot of the open ports did not return a product name. Nevertheless there are some interesting product names to observe like the devices from Siemens, Moxa (automation) and eWON (Industrial VPN Routers: Remote Access & Data Services).
Shodan images
I also made use of the Shodan feature to retrieve the screenshots captured by Shodan. Only one screenshot was found in the result set. I did not made use of the ‘history’ feature of Shodan to retrieve older screenshots.
Conclusion
Retrieving the result set for ICS/SCADA/IoT related queries in Belgium returned some interesting results
- A lot of Rockwell, Moxa and Niagara ICS devices are publicly available. A lot of these devices had their fair share of problems, as reported by ICS-CERT; Based on the network port (this isn’t conclusive but still a good indicator) and product name there are
- 109 ModBus devices
- 97 Rockwell automation devices
- 95 Moxa embedded devices
- 88 eWON ICS remote access devices
- 87 Niagara ICS control systems
- 72 Siemens S7 devices (the overview by product name revealed 116 Siemens devices)
- 54 3S remote management ICS devices
- It seems none of these devices had proper filtering rules (ACLs) in front of them, otherwise Shodan would not be able to track them; There might be other protection measures involved but having these devices wide open makes them vulnerable for further vulnerability testing.
Hack of Polish Financial Supervision Authority and Polish banks
Hack of Polish Financial Supervision Authority and Polish banks
A couple of days back the financial sector in Poland was shocked by the news that the Polish financial supervision authority was hacked and was used as an attack vector to get access to other (mostly Polish) banks.
This is a very short summary with some IOCs (Indicator of Compromise) that you can use to check your logs and verify if you are affected.
Note that most of this information is composed from information found at
- (english) https://badcyber.com/several-polish-banks-hacked-information-stolen-by-unknown-attackers/
- (polish) https://niebezpiecznik.pl/post/jak-przeprowadzono-atak-na-knf-i-polskie-banki-oraz-kto-jeszcze-byl-na-celowniku-przestepcow/
All credit goes to the authors of those posts. I merely merged the info from both posts (and you no longer had to go through Google Translate to read the Polish post).
Note that you can also get the IOCs in an easy accessible format via the OSINT feed of botvrij.eu. If you have a local MISP instance you can subscribe to the botvrij.eu OSINT feed (at no cost). Feel free to contact me if you need help setting up MISP and integrate it in your incident management workflow. Also see MISP EcoSystem – Threat Intelligence, VMRay, MISP. The UUID for this event is 58998603-c66c-49a0-a485-1689c0a8ab16.
Preparation, Delivery, Exploitation and Actions on Objective
- So far there is no evidence that funds of customers of any bank are (or were) at risk
- The attackers (ab)used the trust banks -and their employees- put in the supervision authority
- Protection rules set forward for the banks were not fully applied by the regulator
- The server side attack was made possible because of a not patched vulnerability in JBOSS (stored XSS) and inserted malicious javascript code, this code was then sent to the clients visiting the website
- It’s uncertain if for example CSP would have prevented this attack : “but considering the attack vector and the careful preparation of the attack they would have to be able to work around – modifying, removing CSP or load malicious code from the KNF website”
- There was a similar event (but no claims that it is related to this attack) against the Comisión Nacional Bancaria y de Valores, Mexican financial authority
- The infection of the visitors only took place if the source IP was in the target list (see Target list subnet below)
- Remarkably, the same malicious software was also found at victims that were not in the target list
- The attack exploited vulnerabilities in browser plugins Silverlight and Flash
- Once the malware was injected, it downloaded its final payload from other servers
- Was there a link with other attacks? (info from Polish post) Apparently, the software used is very similar to that used in the SWIFT attack in 2016. A word of warning though. Malware is often developed with the use of libraries. These libraries are shared and reused. Seeing the same characteristics in malware does not mean that it is the same group that conducted he attack. Also, the goal of the so-called SWIFT attackers was financial theft, with the current available information this was not the case for this attack.
- So what was the goal of the attackers?
- There was no financial gain as no funds were stolen
- Was it theft of financial or personal data?
- Financial data (transactions, history) can also be very (more?) valuable
Indication of infection
Web requests
Check your web proxy logs for
knf.gov.pl/DefaultDesign/Layouts/KNF2013/resources/accordian-src.js
or
http://www.knf.gov.pl/DefaultDesign/Layouts/KNF2013/resources/accordian-src.js?ver=11
Other potential malicious URLs included in knf.gov.pl website (check if these requests show up in your web proxy logs)
sap.misapor.ch sap.misapor.ch/vishop/view.jsp?pagenum=1 www.eye-watch.in www.eye-watch.in/design/fancybox/Pnf.action
or
http://sap.misapor.ch/vishop/view.jsp?pagenum=1 https://www.eye-watch.in/design/fancybox/Pnf.action
C2 IPs
C2 IP addresses
1.215.228.230 107.190.190.21 116.168.107.32 120.107.163.79 125.214.195.17 129.221.254.13 131.11.224.116 140.112.14.16 169.45.142.150 17.61.46.70 18.200.16.237 182.45.75.93 196.29.166.218 203.66.57.237 203.67.31.17 204.136.221.47 206.94.195.86 21.190.190.107 218.224.125.66 32.107.168.116 36.61.131.78 47.221.136.204 59.120.19.101 59.173.0.74 59.43.86.123 70.46.61.17 82.144.131.5 86.195.94.206 93.75.45.182
Target list subnet
Only client IPs belonging to these subnets were infected.
10497 | 138.220.0.0 | 138.220.0.0/16 | US | arin | | WORLDBANK - The World Bank Group, US 7734 | 142.205.240.0 | 142.205.240.0/23 | CA | arin | | TDBANK - Toronto Dominion Bank, CA 50432 | 147.114.44.0 | 147.114.44.0/23 | GB | arin | | RBS-GBM-UKSTAFF , GB 15107 | 148.244.42.0 | 148.244.42.0/24 | MX | lacnic | | Grupo Financiero Bancomer, MX 15107 | 148.244.50.0 | 148.244.50.0/24 | MX | lacnic | | Grupo Financiero Bancomer, MX 15107 | 148.244.51.0 | 148.244.51.0/24 | MX | lacnic | | Grupo Financiero Bancomer, MX 21054 | 155.136.0.0 | 155.136.0.0/16 | GB | ripencc | | RBSG-UK-AS Edinburgh, GB 21054 | 155.136.80.0 | 155.136.80.0/24 | GB | ripencc | | RBSG-UK-AS Edinburgh, GB 2824 | 160.83.72.0 | 160.83.72.0/24 | US | arin | | DB-NA-1 - Deutsche Bank, US 2824 | 160.83.73.0 | 160.83.73.0/24 | US | arin | | DB-NA-1 - Deutsche Bank, US 24055 | 160.83.96.0 | 160.83.96.0/24 | US | arin | | DB-APAC-IN-AS Deutsche Bank AG-India Internet AS, IN 24055 | 160.83.97.0 | 160.83.97.0/24 | US | arin | | DB-APAC-IN-AS Deutsche Bank AG-India Internet AS, IN 10497 | 164.114.0.0 | 164.114.0.0/16 | US | arin | | WORLDBANK - The World Bank Group, US 13169 | 167.202.201.0 | 167.202.201.0/24 | NL | arin | | , NL 40375 | 167.222.220.0 | 167.222.220.0/24 | US | arin | | MELLON-EXTRANET-A - Mellon Bank, US 19038 | 168.165.202.0 | 168.165.202.0/24 | MX | lacnic | | SCOTIABANK INVERLAT SA, MX 3147 | 170.135.0.0 | 170.135.0.0/16 | US | arin | | US-BANCORP - U.S. BANCORP, US 2134 | 170.169.127.0 | 170.169.127.0/24 | MX | lacnic | | GSVNET-AS GS Virtual Network Produban, ES 11911 | 170.61.236.0 | 170.61.236.0/24 | US | arin | | BANKOFNEWYORK-AS - The Bank of New York Mellon Corporation, US 11911 | 170.61.237.0 | 170.61.237.0/24 | US | arin | | BANKOFNEWYORK-AS - The Bank of New York Mellon Corporation, US 11993 | 170.66.0.0 | 170.66.0.0/16 | BR | lacnic | | BANCO DO BRASIL S.A., BR 10420 | 170.70.0.0 | 170.70.0.0/16 | MX | lacnic | | Banco de Mexico, MX 10420 | 170.70.18.0 | 170.70.18.0/24 | MX | lacnic | | Banco de Mexico, MX 10420 | 170.70.21.0 | 170.70.21.0/24 | MX | lacnic | | Banco de Mexico, MX 10420 | 170.70.3.0 | 170.70.3.0/24 | MX | lacnic | | Banco de Mexico, MX 10420 | 170.70.36.0 | 170.70.36.0/24 | MX | lacnic | | Banco de Mexico, MX 10420 | 170.70.38.0 | 170.70.38.0/24 | MX | lacnic | | Banco de Mexico, MX 10420 | 170.70.41.0 | 170.70.41.0/24 | MX | lacnic | | Banco de Mexico, MX 10420 | 170.70.6.0 | 170.70.6.0/24 | MX | lacnic | | Banco de Mexico, MX 10420 | 170.70.73.0 | 170.70.73.0/24 | MX | lacnic | | Banco de Mexico, MX 10420 | 170.70.9.0 | 170.70.9.0/24 | MX | lacnic | | Banco de Mexico, MX 10420 | 170.70.92.0 | 170.70.92.0/24 | MX | lacnic | | Banco de Mexico, MX 10794 | 171.159.192.0 | 171.159.192.0/20 | US | arin | | BANKAMERICA - Bank of America, US 10794 | 171.159.48.0 | 171.159.48.0/23 | US | arin | | BANKAMERICA - Bank of America, US 10794 | 171.161.128.0 | 171.161.128.0/18 | US | arin | | BANKAMERICA - Bank of America, US 10794 | 171.192.0.0 | 171.192.0.0/20 | US | arin | | BANKAMERICA - Bank of America, US 131143 | 175.184.246.0 | 175.184.246.0/24 | TW | apnic | 2010-02-01 | CHINATRUST-AS-TW Chinatrust Commercial Bank, TW 52798 | 177.66.196.0 | 177.66.196.0/24 | BR | lacnic | 2012-11-28 | BANCO BTG PACTUAL S.A., BR 20681 | 185.16.140.0 | 185.16.140.0/22 | DK | ripencc | 2013-01-22 | SAXOBANK , DK 60810 | 185.25.108.0 | 185.25.108.0/24 | PL | ripencc | 2013-05-03 | ATMEL , PL 204244 | 185.49.30.0 | 185.49.30.0/24 | PL | ripencc | 2014-02-26 | GLNET-AS , PL 14259 | 190.196.0.0 | 190.196.0.0/24 | CL | lacnic | 2007-07-02 | Gtd Internet S.A., CL 3738 | 192.250.56.0 | 192.250.56.0/23 | US | arin | | SSB-ASN - State Street Bank and Trust Company, US 3738 | 192.250.98.0 | 192.250.98.0/23 | US | arin | | SSB-ASN - State Street Bank and Trust Company, US 24756 | 193.0.242.0 | 193.0.242.0/24 | PL | ripencc | 2002-08-07 | LUKAS-BANK-AS , PL 197220 | 193.104.239.0 | 193.104.239.0/24 | PL | ripencc | 2010-08-10 | IDEABANK , PL 196999 | 193.105.248.0 | 193.105.248.0/24 | PL | ripencc | 2010-03-25 | FMBANK , PL 20705 | 193.108.72.0 | 193.108.72.0/23 | GB | ripencc | 2001-05-11 | HSBC-UK , GB 31528 | 193.16.107.0 | 193.16.107.0/24 | PL | ripencc | 2004-06-07 | BOSBANK-AS , PL 15694 | 193.200.233.0 | 193.200.233.0/24 | PL | ripencc | 2007-06-06 | ATMAN-ISP-AS ATMAN_s ISP Autonomous System, PL 35179 | 193.239.56.0 | 193.239.56.0/22 | PL | ripencc | 2005-06-16 | PROVIDER-WROCLAW ul. Nabycinska 19, PL 41776 | 193.36.183.0 | 193.36.183.0/24 | PL | ripencc | 2006-10-10 | SYGMABANK-AS , PL 9085 | 193.42.211.0 | 193.42.211.0/24 | PL | ripencc | 2005-01-04 | SUPERMEDIA-AS , PL 57170 | 193.8.57.0 | 193.8.57.0/24 | PL | ripencc | 2011-08-10 | ZATM-AS , PL 5588 | 193.84.159.0 | 193.84.159.0/24 | CZ | ripencc | | GTSCE GTS Central Europe / Antel Germany, CZ 29536 | 194.146.120.0 | 194.146.120.0/24 | PL | ripencc | 2003-10-06 | EUROBANK-AS , PL 3308 | 194.255.0.0 | 194.255.0.0/16 | DK | ripencc | | TELIANET-DENMARK , DK 34891 | 194.30.179.0 | 194.30.179.0/24 | PL | ripencc | 2005-04-25 | UM-WARSZAWA-AS pl. Bankowy 3/5, PL 35796 | 194.79.40.0 | 194.79.40.0/22 | RS | ripencc | 2005-10-19 | NBS , RS 31614 | 195.128.0.0 | 195.128.0.0/22 | DE | ripencc | 2004-06-17 | ECB-AS , DE 39095 | 195.142.247.0 | 195.142.247.0/24 | TR | ripencc | | VAKIFBANK-AS , TR 57367 | 195.167.159.0 | 195.167.159.0/24 | PL | ripencc | | ECO-ATMAN-PL ECO-ATMAN-PL, PL 24723 | 195.238.184.0 | 195.238.184.0/22 | PL | ripencc | 2006-06-26 | ATMAN-OFFICE-INTERNET-AS ATMAN, PL 39066 | 195.78.252.0 | 195.78.252.0/24 | UA | ripencc | 2005-12-06 | KREDOBANKUA-AS , UA 15694 | 195.85.227.0 | 195.85.227.0/24 | PL | ripencc | 2003-06-25 | ATMAN-ISP-AS ATMAN_s ISP Autonomous System, PL 12877 | 195.85.249.0 | 195.85.249.0/24 | PL | ripencc | 2003-07-08 | RBPL-AS Raiffeisen Bank Polska S.A., PL 4563 | 198.74.176.0 | 198.74.176.0/24 | US | arin | | BTMU-AMERICA - The Bank of Tokyo-Mitsubishi UFJ, US 394841 | 199.197.16.0 | 199.197.16.0/20 | US | arin | | CBKASN - CoBank, US 22276 | 199.27.240.0 | 199.27.240.0/24 | US | arin | 2010-09-03 | BANKUNITED - BankUnited NA, US 26582 | 199.79.165.0 | 199.79.165.0/24 | US | arin | | IADB-NETWORKS - The Inter-American Development Bank, US 27989 | 200.1.175.0 | 200.1.175.0/24 | CO | lacnic | | BANCOLOMBIA S.A, CO 27853 | 200.10.0.0 | 200.10.0.0/24 | CL | lacnic | | Administradora BANCHILE de Fondos Mutuos, CL 27952 | 200.10.182.0 | 200.10.182.0/24 | CL | lacnic | | Banco Central de Chile, CL 28074 | 200.11.31.0 | 200.11.31.0/24 | SV | lacnic | 2009-08-04 | Banco Azteca El Salvador, SV 262214 | 200.124.125.0 | 200.124.125.0/24 | CO | lacnic | 2012-01-20 | BANCO DE BOGOTA, CO 17249 | 200.13.124.0 | 200.13.124.0/24 | MX | lacnic | | BURSATEC, S.A. DE C.V., MX 14259 | 200.14.138.0 | 200.14.138.0/24 | CL | lacnic | | Gtd Internet S.A., CL 28586 | 200.155.87.0 | 200.155.87.0/24 | BR | lacnic | 2004-11-04 | BANCO BRADESCO SA, BR 6495 | 200.16.40.0 | 200.16.40.0/24 | MX | lacnic | | HSBC Mexico, S.A., Institucion de Banca Multiple, Grupo Financiero HSBC, MX 6495 | 200.16.54.0 | 200.16.54.0/24 | MX | lacnic | | HSBC Mexico, S.A., Institucion de Banca Multiple, Grupo Financiero HSBC, MX 15256 | 200.196.144.0 | 200.196.144.0/20 | BR | lacnic | 2000-05-16 | Itau Unibanco S.A., BR 22055 | 200.218.213.0 | 200.218.213.0/24 | BR | lacnic | 2003-05-02 | Banco Central do Brasil, BR 26620 | 200.23.76.0 | 200.23.76.0/24 | MX | lacnic | | BANCA AFIRME, S.A., MX 6429 | 200.27.96.0 | 200.27.96.0/19 | CL | lacnic | 2001-04-19 | Telmex Chile Internet S.A., CL 27957 | 200.3.1.0 | 200.3.1.0/24 | VE | lacnic | | Banco Mercantil C.A., S.A.C.A.-S.A.I.C.A, VE 28070 | 200.3.147.0 | 200.3.147.0/24 | CO | lacnic | 2009-07-22 | Banco Colpatria Red Multibanca Colpatria S.A., CO 28102 | 200.3.242.0 | 200.3.242.0/24 | PE | lacnic | 2009-12-01 | Banco Azteca Peru, PE 8048 | 200.35.133.0 | 200.35.133.0/24 | VE | lacnic | 2000-06-08 | CANTV Servicios, Venezuela, VE 21980 | 200.35.142.0 | 200.35.142.0/23 | VE | lacnic | 2000-06-08 | Dayco Telecom, C.A., VE 6147 | 200.37.0.0 | 200.37.0.0/19 | PE | lacnic | | Telefonica del Peru S.A.A., PE 6147 | 200.4.192.0 | 200.4.192.0/19 | PE | lacnic | | Telefonica del Peru S.A.A., PE 27725 | 200.55.152.0 | 200.55.152.0/21 | CU | lacnic | 2002-12-09 | Empresa de Telecomunicaciones de Cuba, S.A., CU 28059 | 200.9.111.0 | 200.9.111.0/24 | CL | lacnic | | Banco Hipotecario de Fomento, CL 11172 | 201.131.120.0 | 201.131.120.0/24 | MX | lacnic | 2010-07-16 | Alestra, S. de R.L. de C.V., MX 27989 | 201.221.124.0 | 201.221.124.0/24 | CO | lacnic | 2012-10-22 | BANCOLOMBIA S.A, CO 262247 | 201.221.126.0 | 201.221.126.0/24 | DO | lacnic | 2012-10-26 | Banco Popular Dominicano, DO 24396 | 202.127.170.0 | 202.127.170.0/24 | HK | apnic | 2005-04-15 | BOC-AS-HK Bank Of China(Hong Kong) Limited, HK 17802 | 202.43.140.0 | 202.43.140.0/24 | AU | apnic | 2003-11-17 | MACQUARIE-BANK-AS-AP Macquarie Bank, AU 18421 | 202.6.104.0 | 202.6.104.0/23 | TW | apnic | 2004-03-09 | TAISHINBANK-AS-T Taishin International Bank, TW 45535 | 203.170.25.0 | 203.170.25.0/24 | IN | apnic | 2008-11-26 | AXP-NET-AS-AP American Express Banking Corp., IN 17436 | 203.171.210.0 | 203.171.210.0/23 | IN | apnic | 2008-12-15 | ICICIBANK-AS ICICIBANK Ltd, Banking, Mumbai, IN 45541 | 203.201.58.0 | 203.201.58.0/24 | VN | apnic | 2009-01-23 | BIDV-AS-VN Bank for Investment and Development of VietNam, VN 17802 | 203.210.68.0 | 203.210.68.0/24 | AU | apnic | 2006-04-19 | MACQUARIE-BANK-AS-AP Macquarie Bank, AU 17592 | 203.235.72.0 | 203.235.72.0/24 | KR | apnic | | IBK-AS-KR Industrial Bank of Korea, KR 17436 | 203.27.235.0 | 203.27.235.0/24 | IN | apnic | 2005-05-25 | ICICIBANK-AS ICICIBANK Ltd, Banking, Mumbai, IN 13441 | 205.210.223.0 | 205.210.223.0/24 | CA | arin | | SCOTIABANK - Bank of Nova Scotia, CA 26618 | 207.248.104.0 | 207.248.104.0/24 | MX | lacnic | | Banco Interacciones, S.A., Institucion de Banca Multiple, Grupo Financiero Interacciones, MX 25762 | 208.5.220.0 | 208.5.220.0/24 | US | arin | | BOCUSA - BANK OF CHINA, NY BRANCH, US 10185 | 211.32.31.0 | 211.32.31.0/24 | KR | apnic | | HNB-AS Hana Bank Co., KR 16365 | 212.149.32.0 | 212.149.32.0/19 | DE | ripencc | 2001-03-09 | COMMERZBANK DE-60261 Frankfurt, DE 13042 | 212.39.192.0 | 212.39.192.0/19 | AT | ripencc | 2000-10-03 | ASN-OENB-AT , AT 8904 | 212.40.192.0 | 212.40.192.0/20 | RU | ripencc | | BANK_OF_RUSSIA CBRF Autonomous System, RU 15694 | 212.91.12.0 | 212.91.12.0/24 | PL | ripencc | 2008-05-20 | ATMAN-ISP-AS ATMAN_s ISP Autonomous System, PL 15694 | 212.91.13.0 | 212.91.13.0/24 | PL | ripencc | 2008-05-20 | ATMAN-ISP-AS ATMAN_s ISP Autonomous System, PL 15694 | 212.91.16.0 | 212.91.16.0/20 | PL | ripencc | 2008-05-20 | ATMAN-ISP-AS ATMAN_s ISP Autonomous System, PL 39330 | 212.91.22.0 | 212.91.22.0/23 | PL | ripencc | 2008-05-20 | ARMASAN-AS , PL 57367 | 212.91.26.0 | 212.91.26.0/24 | PL | ripencc | 2008-05-20 | ECO-ATMAN-PL ECO-ATMAN-PL, PL 15694 | 212.91.4.0 | 212.91.4.0/22 | PL | ripencc | 2008-05-20 | ATMAN-ISP-AS ATMAN_s ISP Autonomous System, PL 12483 | 212.93.55.0 | 212.93.55.0/24 | DK | ripencc | | Aarhus Denmark, DK 201489 | 213.189.32.0 | 213.189.32.0/24 | PL | ripencc | 2010-01-08 | HECTOR-SA , PL 201592 | 213.189.40.0 | 213.189.40.0/24 | PL | ripencc | 2010-01-08 | GTU_SA , PL 24757 | 213.55.64.0 | 213.55.64.0/21 | ET | afrinic | 2000-10-12 | EthioNet-AS, ET 26380 | 216.119.215.0 | 216.119.215.0/24 | US | arin | 2003-01-02 | MASTER-7-AS - MasterCard Technologies LLC, US 30346 | 216.83.80.0 | 216.83.80.0/24 | US | arin | 2003-09-16 | TBD - Sumitomo Mitsui Banking Corporation, US 197155 | 217.149.240.0 | 217.149.240.0/24 | PL | ripencc | 2004-06-15 | ARTNET , PL 12794 | 217.169.192.0 | 217.169.192.0/22 | TR | ripencc | 2001-03-27 | AKNET-AKBANK , TR 15694 | 217.17.32.0 | 217.17.32.0/20 | PL | ripencc | 2000-09-13 | ATMAN-ISP-AS ATMAN_s ISP Autonomous System, PL 15694 | 46.229.144.0 | 46.229.144.0/20 | PL | ripencc | 2011-02-17 | ATMAN-ISP-AS ATMAN_s ISP Autonomous System, PL 24723 | 46.229.158.0 | 46.229.158.0/24 | PL | ripencc | 2011-02-17 | ATMAN-OFFICE-INTERNET-AS ATMAN, PL 24723 | 46.229.159.0 | 46.229.159.0/24 | PL | ripencc | 2011-02-17 | ATMAN-OFFICE-INTERNET-AS ATMAN, PL 16539 | 50.203.36.0 | 50.203.36.0/24 | US | arin | 2010-10-21 | MERCANTILCB - Mercantil Commercebank, N.A., US 23291 | 63.78.207.0 | 63.78.207.0/24 | US | arin | | FLAGSTAR-BANK-US - Flagstar Bank, US 36464 | 74.118.216.0 | 74.118.216.0/24 | US | arin | 2009-10-16 | RABOBANK-AMERICAS-NYW - Rabobank International, US 24748 | 77.79.192.0 | 77.79.192.0/24 | PL | ripencc | 2007-03-14 | ATMAN-POLAND-AS ATMAN_s Poland Autonomous System, PL 197474 | 77.79.230.0 | 77.79.230.0/23 | PL | ripencc | 2007-03-14 | ASECUREX , PL 35179 | 79.110.192.0 | 79.110.192.0/20 | PL | ripencc | 2008-06-10 | PROVIDER-WROCLAW ul. Nabycinska 19, PL 35179 | 79.110.193.0 | 79.110.193.0/24 | PL | ripencc | 2008-06-10 | PROVIDER-WROCLAW ul. Nabycinska 19, PL 35179 | 79.110.206.0 | 79.110.206.0/23 | PL | ripencc | 2008-06-10 | PROVIDER-WROCLAW ul. Nabycinska 19, PL 5617 | 80.48.0.0 | 80.48.0.0/14 | PL | ripencc | 2001-12-18 | TPNET , PL 60813 | 81.90.96.0 | 81.90.96.0/24 | ES | ripencc | 2002-07-03 | BSABADELL , ES 15694 | 85.232.224.0 | 85.232.224.0/19 | PL | ripencc | 2005-04-15 | ATMAN-ISP-AS ATMAN_s ISP Autonomous System, PL 197431 | 85.232.225.0 | 85.232.225.0/24 | PL | ripencc | 2005-04-15 | GEMIUS-NETWORK , PL 15810 | 89.107.183.0 | 89.107.183.0/24 | ES | ripencc | 2006-05-12 | BBVA-AS Spain, ES 39632 | 91.208.26.0 | 91.208.26.0/24 | EE | ripencc | 2008-07-04 | EESTIPANK (Bank of Estonia), EE 20705 | 91.214.4.0 | 91.214.4.0/23 | GB | ripencc | 2009-05-06 | HSBC-UK , GB 197124 | 91.226.117.0 | 91.226.117.0/24 | PL | ripencc | 2011-04-20 | INVESTBANK-AS , PL 9016 | 91.228.112.0 | 91.228.112.0/24 | PL | ripencc | 2011-05-27 | KBS-BANK-AS , PL 34891 | 91.237.138.0 | 91.237.138.0/23 | PL | ripencc | 2012-03-26 | UM-WARSZAWA-AS pl. Bankowy 3/5, PL 58077 | 91.238.78.0 | 91.238.78.0/24 | PL | ripencc | 2012-04-10 | ESBANK-AS , PL 39603 | 94.254.128.0 | 94.254.128.0/20 | PL | ripencc | 2008-10-07 | P4NET P4 UMTS operator in Poland, PL
Calendar invite spam
Calendar invite spam
I received some unusual calendar invite spam. In total in consisted of 4 messages :
- a calendar invite
- quickly followed by the cancellation of the invite
- a new calendar invite
- the cancellation of the last invite
Calendar invite spam isn’t that uncommon but compared to the total amount of spam the amount of calendar invite spam is still fairly low.
In this case I found the series of messages (invite – cancel – invite – cancel) unusual. Either the spammer made an error or they just wanted to make sure to get the needed attention from their intended recipients.
Characteristics of calendar invite spam
Some characteristics of the calendar spam invite
- From: “George Rowland” <rowlandgeorge @ yahoo.com>
- Subject: Invitation: ATTENTION, PLEASE TRY TO CONTACT Mr.Kevin green OR CALL HIM REGARDING YOUR $9,000?
- Sent via the Yahoo mail servers
- Invite to calendar.yahoo.com
- Request to submit information to offficefilesettlement @ gmail.com
- Both invites contained 40 recipients, the recipients between both invites were different
- No links or external resources included, the only link in the message was the one to the Yahoo servers for accepting or declining the invite
The message itself looked like this :
Efficiency of calendar spam
I still have to understand what would make this type of spam more efficient than “regular” spam.
From a spammer point of I would think that the success rate might be lower. On the other hand, trying different delivery methods is “good practice” and the amount of effort needed for sending these messages (assuming they use tooling) is relatively low.
- These calendar invites contain the list of other people invited, this list is visible if your scroll through the event (at least for me that’s common habit to check who else is attending an event)
- The chances that any of the other recipients are known to you are fairly low, this should make you have doubts about the legitimacy of the invite (granted, in this case the content of the invite itself was already enough to raise suspicion). Some “normal” spam messages also put all the recipients in the “To” but in a lot of cases you’re the only -visible- recipient
- This particular message required some interaction, no phishing link included
Don’t Let Remote Management Software Contribute to Building Botnets
I published an article on IBM Security Intelligence on Don’t Let Remote Management Software Contribute to Building Botnets.
MISP EcoSystem : Threat Intelligence, VMRay and MISP
I made a slide-deck on integrating MISP and VMRay in your incident management workflow.
