Upcoming Windows Server TGT updates may break authentication. Summary Microsoft has recently taken to the Reddit community regarding upcoming changes to Kerberos TGT delegation; these changes may cause service disruption for the unprepared.   The Change The update itself will cause the default value of EnableTGTDelegation to change from Yes to No and is due to take place during the May/July 2019 patch cycle.   Will I be affected? Unconstrained delegation across forests is a common way for organisations to manage authentication over multiple forests. If EnableTGTDelegation is not set explicitly on your domain controllers, this change to the default setting will break any application or service that relies on unconstrained delegation across forests. Microsoft has provided a PowerShell script to help identify any possibly affected services, please refer to this KB article.   Vulnerability Microsoft has provided the following reason for why they have decided to make this change: The current default configuration for this feature is unsafe when incoming trusts are created.  This is because the configuration lets an attacker in the trusting forest request delegation of a TGT for an identity from the trusted forest.   If you would like a more in-depth explanation of the changes or how to prepare, please check out Microsoft’s TechCommunity blog and the relevant patch notes.

Don't be an April Fool – back up your files! This Sunday the 31st of March marks World Backup Day [1]. Why backup? Backups are crucial for ensuring the integrity of your files in any unexpected event.  If you aren’t already convinced on the utility of backups, or if they aren’t at the top of the priority list, here’s a handy list to change your mind (or to convince the boss it’s important!) – Disaster recovery: from flood and fire to dead hard drives and the accidental rm -rf– Forensics and auditing: to find out when something changed or when a machine is compromised– Ransomware recovery: so we don’t have to negotiate with scammers– Device theft or loss: hardware is replaceable, the data should be too– Minimising down time: in the event of data loss, you want the business back up and running as soon as possible Snapshots can help with some of these things, but snapshots aren’t backups, so having both is important. Storing your Backups Securing your backups is important to ensure the integrity and confidentiality of your data.  Keep your backups on servers you trust, and have at least one copy offsite, in the case of a natural disaster.  Duplicity or Duply [2] are powerful tools which can gpg-encrypt your backups to send to an Amazon S3 bucket or elsewhere.  Popular cloud services include Backblaze [3], or Time Machine for Mac [4].   Testing your Backups If you already have backups, which fingers crossed we all do, take this event as an opportunity to test them.  Try to include data recovery testing with your regular maintenance or patch cycle – just because they worked once, doesn’t mean they always will. The worst time to test your backups is when your data is gone, the best time is right now! Charelle   [1] http://www.worldbackupday.com/en/[2] https://duply.net/[3] https://www.backblaze.com/[4] https://support.apple.com/en-us/HT201250

Password Reuse and Data Breaches Everyone knows the story of registering for a website we only ever intend to use once, where we lazily re-used a password. Fast forward 15 years later, you find out that website’s password database was storing everything in plain text, someone bad got a hold of it and you never knew. It’s a surprisingly common story and there is a stigma of shame around talking about personal password hygiene. One thing we can all do is tell the people we are close to that it’s never too late to start improving, recommended password managers and good multi-factor solutions to get the ball rolling for them.  Password reuse is hard to get out in the open as it is a very private issue. Luckily, there is now a solution. Troy Hunt has teamed up with Cloudflare to provide a free API that allows passwords to be checked against known passwords that have been seen in reported breaches. Steer people in the direction of Troy Hunt’s Have I Been Pwned website and it may give them the wake up call they need, when a big scary red box flashes up on the screen letting them know that their data may not be safe.   What can we do then on an organisational level? The personal touch of reaching out to people directly doesn’t scale well and can often come across as intimidating when coming from “the security team”. The experience of setting a password is a very private one and the strong password guidelines need to make their way into this personal experience. We have been asking users to set things like reasonable password lengths and complexities through web frameworks for a long time now. The instant responsiveness of this has been training everyone that password length and complexity matter, but what about reuse? Troy teamed up with Cloudflare to deliver a free API endpoint to check if a password has shown up in reported data breaches last year. What this means for organisations is that on your password reset page or even login page you can query this API endpoint every time you type in a password so see if it has shown up in a breach before.   Doesn’t that mean Troy now has my new password? Nope! The API has been designed so that only the prefix of the hash of your password is sent to the API endpoint and you get back all hashes that match that prefix, you then check to see if your hash matches any of the returned results. Hashes are designed for obfuscation so sending through the first five characters of your hash doesn’t reveal your password. Passwords that will have the same first five characters will have no relevance to one another. For example the first five characters in the hash for “alexguo029” is “21bd1”, while the first five characters in the hash for “lauragpe” is also “21bd1”. Therefore if an attacker was able to capture the data sent to the API they will not be able to gather any sensitive information. Read more about the technical details in Troy’s blog.   Can I easily implement it on my infrastructure? Yes! We can query this API in client-side code without ripping apart any of our current systems. Client-side code works for this as it’s more of a user education exercise than another security layer. Check out some implementations on GitHub like passprotect-js to see just how easy it is. There is a great demo video and example code showing how the prefix of the password hash is generated and sent to the API and instantly gives the user feedback showing the tangible evidence that the password is not safe to use.  This is an easy win and with the recent password collection dumps it is more valuable then it has ever been. Run it in a development environment today as a proof of concept. To lead by example this is a demo I ran up on the AUSCERT website just this morning using passprotect-js.     What do I do about the latest breach? We can’t eliminate password reuse for our user-base. Password rotation policies feel like a natural solution to this however NIST warns of aggressive password rotation lowers the overall password strength due to user fatigue. Check out if your organisation shows up in a breach. Hopefully the passwords are not reused but you should still encourage resets where possible especially for users which could be high value targets.   Use MFA! Human brains will never be great at password based authentication, that is why we need to supplement it with another factor. This takes the urgency out of password breaches with respect to password reuse in your organisation because of the second line of defence. We use one time password based MFA on the AUSCERT website and hope to extend it to our other services in the future.

What do I need to know about the MSP hack? What’s going on? On Thursday, the United States Justice Department made an indictment against two members of APT10, acting in association with the Chinese government [0]. APT10, an advanced persistent threat, has been targeting managed service providers (MSPs) around the world since 2014. Organisations from over fourteen countries were affected, including Australia. This indictment has spurred a flurry of new stories this morning, including a publication from the ACSC [1] and an interview with National Cyber Security Adviser, Alastair MacGibbon [2], who also attributes APT10 to the Chinese Government. The nation-state attack on MSPs was covered extensively in 2017, as well as earlier this year [3] [4], and is known as “Cloud Hopper” [5]. This attack attempts to compromise the MSP with remote access trojans (RATs) delivered by phishing. By compromising MSPs, attackers are able to then target the MSP’s clients. What is APT10? APT10 is also known as Stone Panda, MenuPass, and Red Apollo. An APT is skilled and persistent with more resources than other types of attackers, so they are usually sponsored by nation-states, or coordinated groups. When the APT10 MSP attacks were reported in 2017, there was only circumstantial evidence which pointed at Chinese timezone patterns. This indictment from the US Justice Department charges APT10 members Zhu Hua and Zhang Shilong, who acted in association with the Chinese Ministry of State Security’s Tianjin State Security Bureau since 2006. What should I tell my boss? This is not a new threat, and we have known about it since early 2017. The reason it is in the news is that the United States Justice Department has indicted two Chinese nationals. You can also point out which of the controls in this document you have implemented to mitigate the risks associated with engaging with an MSP: “How to manage your network security when engaging a Managed Service Provider” [6] What you should do At the time of writing, here are the Indicators of Compromise from our MISP event:https://wordpress-admin.auscert.org.au/publications/2018-12-21-apt10-msp-breach-iocs We recommend running these against your systems and logs. While a list of affected MSPs isn’t publicly known, the ACSC has contacted any MSPs they know to have been affected. If you have any concerns, we recommend you contact your MSP, as they will be able to provide more information about their situation. You can also take this opportunity to update your risk registers and incident plans for any information and services you have hosted with a third party provider. Perhaps you could make it a start or end of year routine?   With that said, have a relaxing holiday season – we hope you don’t have to play too much family tech support!   [0] https://www.justice.gov/opa/pr/two-chinese-hackers-associated-ministry-state-security-charged-global-computer-intrusion[1] https://cyber.gov.au/msp-global-hack/[2] https://www.abc.net.au/radionational/programs/breakfast/australian-businesses-hit-by-audacious-global-hacking-campaign/10645274[3] https://www.arnnet.com.au/article/617425/aussie-msps-targeted-global-cyber-espionage-campaign/[4] https://www.securityweek.com/dhs-warns-attacks-managed-service-providers[5] https://www.pwc.co.uk/cyber-security/pdf/cloud-hopper-report-final-v4.pdf[6] https://cyber.gov.au/business/publications/msp-risk-for-clients/

Windows DNS Server Privilege Escalation vulnerability (CVE-2018-8626) leading to Remote Code execution alleged to have Proof of Concept exploit INTRODUCTION AUSCERT recently published an ASB addressing Microsoft’s security updates for the month of December.  Among the vulnerabilities addressed was a Critical vulnerability in the DNS Server implementation in the following Windows platforms: “Windows 10 Version 1607 for 32-bit SystemsWindows 10 Version 1607 for x64-based SystemsWindows 10 Version 1709 for 32-bit SystemsWindows 10 Version 1709 for 64-based SystemsWindows 10 Version 1709 for ARM64-based SystemsWindows 10 Version 1803 for 32-bit SystemsWindows 10 Version 1803 for ARM64-based SystemsWindows 10 Version 1803 for x64-based SystemsWindows 10 Version 1809 for 32-bit SystemsWindows 10 Version 1809 for ARM64-based SystemsWindows 10 Version 1809 for x64-based SystemsWindows Server 2012 R2Windows Server 2012 R2 (Server Core installation)Windows Server 2016Windows Server 2016 (Server Core installation)Windows Server 2019Windows Server 2019 (Server Core installation)Windows Server, version 1709 (Server Core Installation)Windows Server, version 1803 (Server Core Installation)” [1] Security updates fixing the vulnerability have been provided by Microsoft.   VULNERABILITY DESCRIPTION In their vulnerability description, Microsoft states: “A remote code execution vulnerability exists in Windows Domain Name System (DNS) servers when they fail to properly handle requests. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the Local System Account. Windows servers that are configured as DNS servers are at risk from this vulnerability. To exploit the vulnerability, an unauthenticated attacker could send malicious requests to a Windows DNS server.” [1] Failed exploitation attempts will lead to denial of service conditions.   NVD CVSS3 Vector:  AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C NVD CVSS3 Base Score: 9.8 (Critical)   PROOF OF CONCEPT EXPLOIT Although the NVD CVSS3 vector above indicates a proof of concept exploit exists for this vulnerability, AUSCERT has not been able to access it or find any threat indicators related to it. We will continue to update this blog as more information becomes available.   References 1. https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8626

What Scotty Didn't Know – your guide to domain takeovers Last night, a domain belonging to our PM lapsed, resulting in a cheeky citizen snapping it up [1]. If your business lost control of its domain, what would you do? Losing your domain can greatly impact business operations – email will stop working, customers won’t be able to access your website, soon calls and tweets start coming in. In a worst case scenario, someone with malicious intent can claim the domain, start receiving sensitive business emails, receive password reset emails for online services, and start sending emails as you. Not only does this look unprofessional, but can significantly impact service to your clients, your access to other services (via email password resets), and impact business revenue. Fortunately, prevention is as simple as not letting the renewal get lost in a sea of tasks: – See if your registrar allows automatic renewal, and make sure your payment details are kept up to date– Set an alert far enough in advance to get the expense approved and paid– Don’t ignore emails from your registrar, but also don’t click links in the email. It is always safer to go directly to their website– Related to the previous point, watch out for scam emails claiming to be from a registrar. They often use urgent wording to try get you to click ICANN is the Internet Corporation for Assigned Names and Numbers. They control generic top level domains (gTLD) such as .com, .net, .space. The number of gTLDs is expanding, but there are currently over 1900 that have been delegated. ICANN policy allows a 30 day redemption grace period where the registered name holder can renew a lapsed gTLD. The .au TLD is a country code top level domain (ccTLD). In Australia, the .au top level domain, which includes .com.au, .gov.au, .net.au, .edu.au, is controlled by auDA – .au Domain Administration Ltd [2]. auDA’s domain name renewal policy for lapsed domains is also 30 calendar days after expiry. Conveniently, for potential scammers, there is a public list of expired domain names, updated daily. [3] If someone has taken your .au domain and is trying to sell it back to you, this is called cybersquatting, and not allowed according to auDA’s policies:“A registrant may not register a domain name for the sole purpose of resale or transfer to another entity.” [4]In this scenario, you would be able to file a complaint with auDA.   Registering similar domains So you have awesomebusiness.com.au … but what if someone buys awesomebusiness.com? Or awesomebusiness.tk? Domains are fairly cheap, so it often doesn’t hurt to buy the more common ones, like .com or .net If you follow this route, try not to let them lapse as well! If someone does register a domain that infringes on your trademark, it may be possible to have it de-registered. We recommend speaking with your legal department for advice. AUSCERT is only able to issue takedowns for malicious domains that are used to distribute malware or phishing campaigns. Subdomain takeoversIt would be remiss to have a post about domains but not mention subdomain takeovers. This often occurs when CNAME records aren’t kept up to date. For example, say you have campaign.awesomebusiness.com.au which points to hosting.cloud.com. After the campaign ends you take down the site, but forget remove the CNAME record. This would allow someone else to establish a service on hosting.cloud.com, and set up a phishing site for your users at campaign.awesomebusiness.com.au. To prevent this, include updating DNS in your decommissioning process, and periodically check your DNS zone file. While domain threats are not often at the forefront of our minds, a little bit of housekeeping can go a long way to prevent an embarrassing incident in the future. Charelle. [1] https://web.archive.org/web/20181018222134/http://www.scottmorrison.com.au/[2] https://www.auda.org.au/[3] https://afilias.com.au/about-au/domain-drop-lists[4] https://www.auda.org.au/policies/index-of-published-policies/2012/2012-04/

Targeted blackmail campaign gains momentum Since the dawn of email, spam has constantly pushed our ability to handle arbitrary, unsolicited input. Whether through gauntlets of long-forgotten regexes, or the most sophisticated of convolutional neural nets, detecting and blocking spam has been a Sisyphean battle which has consumed countless IT resources. Not so at AUSCERT. We have the dubious luxury of actively soliciting spam wherever it is to be found. Because of this we’re able to watch as campaigns wax and wane, see how they evolve over time, and get a feel for the objectives of the spammers. Some campaigns are evergreen – fake pharmaceuticals (usually of the male enhancement variety), various advance-fee scams (think Nigerian Prince), phishing for credentials – it’s rare a day goes by without examples of these coming across our inbox. Some campaigns are very flavour-of-the-month, for a few months everyone had their own ICO or crypto investment strategy to hawk to any mail socket willing to listen(). Other campaigns are more sporadic. It’s not unusual for us to see a short burst of activity on one particular topic or script which goes silent, only to re-emerge later. Sometimes this is to facilitate a transition to new infrastructure, or to replenish their supply of compromised accounts. Other times this can be to spend time reworking the script, or refining their technique – this blog deals with one such instance where the renewed campaign was so successful that we’ve seen a large uptick in its output. This particular campaign is a faux sextortion blackmail. The premise of the blackmail is that the spammer has recorded the recipient visiting a pornographic website, through some vulnerability on the website or the recipient’s own computer. Unless the victim pays a sum of cryptocurrency to the spammer, they threaten to release this non-existent video to the victim’s family, friends, or colleagues. The campaign itself is far from new, we have seen minor variations on the same script pop up repeatedly. Recently a new variation emerged, almost exactly the same, but with one small difference: it would present the recipient’s password to them. Given that these passwords were usually out of date, and data breaches and dumps are a great source of email address for spam campaigns, it stands to reason that the spammers were simply pulling passwords for a given email from old breaches and inserting them into the email template. In fact, in our case it would seem if they cannot find a matching password then it fills that portion of the template in with an empty string. We’re certainly not the first to have written about this campaign,[1] but we were spurred to write this post due to the increase in its prevalence that we’re witnessing. Unfortunately this only means one thing: it’s working. We’re also now seeing campaigns where the recipient’s name and phone number are being used in place of the password. It’s not hard to see how as an unsuspecting recipient you could easily be fooled into believing the claims made. Indeed, efforts to catalogue and track the transactions of the various wallet addresses used by the spammers prove that it’s having the desired effect.[2] Some things you can do to protect yourself against such scams: Treat all unsolicited email with a healthy dose of skepticism. If you receive any threatening email, take a sentence or two and search for them. This can help you detect if you’ve received a well-known script or variant. Report the email to your IT department if possible. Practice good password hygiene. If you know you’ve used a strong, unique password for each service then you reduce your exposure when one is breached. Consider a password manager. For reference, here is an example from this campaign that we have received: It appears that, (), is your password. May very well not know me and you are probably wondering why you're getting this e-mail, right? actually, I put in place a malware over the adult videos (adult porn) website and guess what happens, you visited this web site to have fun (you really know what What i'm saying is). When you were watching videos, your internet browser started off working like a RDP (Remote Desktop) which provided me accessibility to your screen and web camera. from then on, my software program obtained your complete contacts from your Messenger, Microsoft outlook, Facebook, as well as emails. What did I really do? I created a double-screen video clip. First part shows the recording you were seeing (you have a good taste haha . . .), and 2nd part shows the recording of your webcam. what exactly should you do? Well, in my opinion, $1200 is a fair price for your little secret. You will make the payment by Bitcoin (if you do not know this, search "how to buy bitcoin" in Google). Bitcoin Address: **ADDRESS** (It is case sensitive, so copy and paste it) Very important: You've got some days to make the payment. (I have a unique pixel in this e-mail, and at this moment I know that you've read through this email message). If I do not get the BitCoins, I will certainly send your videos to all of your contacts including relatives, co-workers, and so forth. Having said that, if I receive the payment, I'll destroy the recording immidiately. If you'd like evidence, reply with "Yes!" and I will definitely mail out your videos to your 6 contacts. It is a non-negotiable offer, that being said don't waste my personal time and yours by answering this message. [1] https://krebsonsecurity.com/2018/07/sextortion-scam-uses-recipients-hacked-passwords/[2] https://twitter.com/SecGuru_OTX/status/1022430328647024640

Location, location, location This week we received an email from a person who was concerned about a picture they had uploaded to their profile within an organisation.  They noticed that the GPS coordinates of where the photo was taken was retained in the metadata of the uploaded image.  Curious, they started looking at other people’s profile images to discover coordinates stored in those as well, potentially revealing where these colleagues live. What is EXIF data? Apart from the image itself, an image file can store other information such as date, time, camera information and settings, geolocation, and copyright information. For a photographer, this information is very useful, and saves having to write it down for each photo.  What it also means though, is that when we take a photo with a camera phone, and upload this image to social media, that site now has access to where you are, and at what time you were there.  Not only that, but if the website doesn’t strip the metadata before republishing, others could also see this information and track your location and movements. What can I do? For users: Many social media websites already strip location and other EXIF data, including (at the time of writing) Facebook, Instagram, LinkedIn and Twitter. That said, many other large sites do not strip this metadata, and it can be difficult to know about smaller services or corporate systems, so as a user, it is safer to disable the saving of location information from your device. On Android, this will vary depending on your phone and version. In your camera application, look for ‘Settings‘, then ‘GPS location‘ or ‘Store Location‘, and turn this option off. You can also disable location services completely by going to ‘Settings‘, then under the ‘Personal‘ heading, select ‘Location‘ and turn it off. On an iPhone, in ‘Settings‘ go to ‘Privacy‘, then ‘Location Services‘ and turn this option off for the camera. These steps only disable location information. Time and date stamps, as well as device information will still be retained. For existing photos on your computer, you can use Imagemagick (https://www.imagemagick.org, cross platform) to batch strip EXIF data from your images: $ mogrify -strip * In Windows, you can right click an image, select ‘Properties‘, then the ‘Details‘ tab to see and remove the image’s metadata. Alternatively, there are many other image editing tools to choose from.   For administrators: Please look into stripping metadata when a user uploads an image to your web application, or re-process images so that data isn’t available to other users. Happy (and safe) snapping!Charelle.

Insecure AWS S3 buckets – an ongoing target Recently, AUSCERT has seen an increase in the number of attacks on unsecured cloud infrastructure. One of the most frequently targeted cloud hosting methods is Amazon’s Scalable Storage Solution, commonly referred to as AWS S3.   S3 is used to store static assets for public websites, such as images and javascript, and is also used as a destination for backup solutions, due to its low storage costs. S3 buckets can be accessed via HTTP/HTTPS, as well as an API that is available to other AWS infrastructure.    However, critically, many buckets have been configured to expose all of their files, as well as a listing of the files in the bucket – a modern equivalent to the open directory listing issue that many misconfigured webservers have suffered from in the past.   Perhaps due to an overload of new practices required when switching to AWS infrastructure, or due to unfamiliarity with the platform, many S3 buckets have been left exposed when they contain sensitive or secret data, such as backups, copies of databases, or private documents. Many of these S3 buckets have been discovered by third parties, which has resulted in some high-profile data breaches. This website maintains a listing of data breaches that were caused by insecure S3 buckets.   Although this issue has been known for a long time, in the last 12 months more tools to enumerate, discover, and even provide public search listings of S3 buckets have become available. This recent trend has prompted AUSCERT to begin scanning AWS for S3 buckets that have easily guessable names relating to our members’ organisations.   Amazon themselves have noted this issue and have taken measures to assist users and prevent further compromises on their platform. Last year, after a large breach that affected millions of Dow Jones customers, Amazon sent an email to the account administrator of every AWS account that had publicly accessible S3 buckets.   In Amazon’s own words, “While there are reasons to configure buckets with world read access, including public websites or publicly downloadable content, recently, there have been public disclosures by third parties of S3 bucket contents that were inadvertently configured to allow world read access but were not intended to be publicly available. We encourage you to promptly review your S3 buckets and their contents to ensure that you are not inadvertently making objects available to users that you don’t intend.”   The official AWS blog contains useful information about securing S3 buckets while still allowing access in a controlled manner. See this article, published in March 2018, for more details.   AUSCERT recommends reviewing all of your AWS infrastructure to ensure access controls are appropriate for your uses.     Anthony Vaccaro, Senior Information Security Analyst at AUSCERT

Malicious emails via WeTransfer AUSCERT has seen direct evidence of malicious emails being sent via WeTransfer, as part of an ongoing campaign affecting Australian organisations. We have summarised our findings and provided advice, which can be found at the end of this post. WeTransfer is a legitimate file-hosting service with a simple business model: users can upload a file, enter a recipient email address, and enter a sender email address. The uploaded file will be sent to the recipient with an explanatory email template, and the sender will also receive an email receipt. However, WeTransfer perform minimal validation on email addresses provided by users, which is a major security hole. By default, users may enter any sender address. The WeTransfer FAQ makes it clear that they allow address spoofing on purpose: “Our ease of use is a core value, that’s why we allow our users to enter any email address they want. This sometimes has the effect you are experiencing, where someone else uses your email address. Most likely even by mistake!” An attacker can enter something like the following: This will send a legitimate-looking file transfer email to both parties, using WeTransfer’s branding and legitimate email headers.     This means that WeTransfer is allowing targeted phishing and malspam emails to be delivered, based on the strength of their own brand. This vulnerability, and others, have been known for months.    When AUSCERT contacted WeTransfer to report this security hole, we received a response, the gist of which was: They’ve blocked the sender and their IP address. They’ve removed the malicious file, so nobody can download it. They consider this kind of abuse a “very rare effect”. They have a “new email verification feature”. Fill out a form and they’ll send a verification token to your email address every time it is used as a sender. They can block a specific email address so it cannot be used to send spam.   This is inadequate, for the following reasons: Verification of the sender should be default, not opt-in. IP address blacklists provide minimal security. It is not the responsibility of an organisation or individual to disallow third-party services from spoofing them.   AUSCERT recommends: All emails sent from WeTransfer should be treated as suspicious. Until mail blacklists begin to block WeTransfer’s emails automatically, flag suspicious emails as junk. Mail administrators should consider looking for recent WeTransfer emails and following up with users. Malicious emails are sent from noreply@wetransfer.com.

Russia, diplomacy and potential repercussions in Australian cyberspace Background We recently witnessed the “largest expulsion of Russian diplomats” by 27-odd countries in support of the UK, following the attempted murder of a Russian double agent on British soil. Russia in turn directed threats of retaliatory action to the countries involved, including Australia. Australia has signalled intent to boycott the World Cup, which will be held in Russia this year. With the Gold Coast Commonwealth Games on right now, that may be just be sufficient cause for Russian “cyber activists” to direct some nasty traffic our way.   Russia’s track record of using cyber attacks in support of its political agenda [1] 2007, Estonia. Large scale DDoS attack.            Triggered by planned relocation of a Russian World War 2 memorial. 2008, Lithuania. Government site defacements.            Triggered by the Lithuanian government banning display of Soviet symbols. 2008, Georgia. Internal communications shutdown.            Triggered by Georgia sending troops to reclaim a breakaway republic supported by Russia. This was followed by a Russian military invasion. 2009, Kygyzstan. DDoS against two ISPs.            Triggered by the need to exert pressure on the government to evict a US military base. It worked! 2009, Kazhakstan. DDoS on media outlet.            Triggered by release of an article that was critical of Russia. 2009, Georgia. DoS of Twitter and Facebook in Georgia.            Triggered by the first anniversary of the invasion of  Georgia! 2014, Ukraine. DoS on Ukrainian election commission.            Triggered by attempts to create chaos in support of the pro-Russian candidate. 2015, Germany. Compromise of German Bundestag.            Triggered by an attempt to retrieve information on German and NATO leaders. 2015, Holland – Pull out reports on MH17 investigation. 2015, USA. Compromise of Democratic Party computers.            Triggered by attempts to undermine elections. 2016, Finland. Compromise of Finnish foreign ministry computers. 2016, Germany. Emerging claims of malicious activity being conducted by Russian hackers to discredit incumbent chancellor, Angela Merkel.   Increasing confidence The above sequence indicates an increasingly confident nation state, reaching further and deeper into foreign spheres to satisfy its political agenda. One common thread in all the above attacks is an attempt to highlight weaknesses in the targeted country’s government and/or commercial infrastructure. Even stealthy attacks, once exposed to the media, serve to question the security posture of the victim nation.  While the above list contains all the acts attributed to Russia, other nation states, such as North Korea have also been attributed with malicious acts against other nations. Perhaps most significant in the context of the Commonwealth Games is the “Olympic Destroyer” [2] malware that was deployed against South Korea during the Pyeongchang winter Olympics. This malware was capable of permanently damaging computer systems employed in the games.   What does this mean for us? Possibly a two prong approach: Noisy hacktivist type attacks Government website defacements (e.g. foreign ministry) Commonwealth games site defacement Denial of Service attacks against Commonwealth Games infrastructure (similar to Olympic Destroyer) Stealthy attacks Advanced Persistent Threats (APTs) to obtain sensitive data from Government and commercial entities Harvesting Commonwealth Games visitor information (which the Gold Coast City Council admitted doing, by collecting user’s Facebook accounts when they connect to the high-speed public Wi-Fi network) How can we protect ourselves? Tune preventive controls to indicators of exploit traffic, DDoS traffic, and APTs. Have a DDoS response plan. [3] Watch for acts of cyber-aggression against countries threatened with retaliation as a potential indicator of elevated threats again Australia Don’t use unprotected public Wi-Fi networks (or “protected” public Wi-Fi networks). If you absolutely must, use encrypted chat channels and mail clients for communication. Elevated monitoring of Industrial Control System processes and infrastructure for anomalous behaviour. Read Security bulletins for the latest vulnerabilities affecting devices and software in your environment that might be exploited, and take necessary measures to patch them based on a risk-based prioritisation schedule   References https://www.nbcnews.com/storyline/hacking-in-america/timeline-ten-years-russian-cyber-attacks-other-nations-n697111 http://blog.talosintelligence.com/2018/02/olympic-destroyer.html https://zeltser.com/ddos-incident-cheat-sheet/  

25 Years of AUSCERT AUSCERT celebrates 25 years today There has been a lot of growth in the industry since the original SERT (Security Emergency Response Team) was formed in 1993. Three Brisbane based universities formed the SERT originally, Queensland University of Technology, Griffith University and The University of Queensland. Originally the SERT was formed for several reasons. One was in response to Australia being recognised as a targeted geographical location for cyber security threats. Also, back in 1992, Australia was the origin of an increasing number of these attacks, which targeted overseas websites. Relationship building with international CERTs began at this time, with the CERT Coordination Centre in Pittsburgh and the DFNCERT team in Germany being incredibly vital to the growth of Australia’s first CERT. In the early days an exercise book was used to log all incoming calls, including wrong numbers. Indeed one of those original staff members, whose initials are inscribed in that book, is an AUSCERT employee today. AUSCERT began in name on the 1st April, 1994, this was made possible by a collaboration with AARNet, who at that time were quite new themselves, only having been in operation for several years. AUSCERT became a member organisation in the late nineties, and has since been funded by our members.   The AUSCERT team is driven by a passion to protect, assist and engage with the information security community. We will continue to provide first class threat intelligence, unique membership options and advice now, and in the future.