Sobre o horário de verão 2018:
==========================================

Conforme última atualização do decreto 6658, o horário de verão brasileiro está definido da seguinte forma:

Horário de verão inicia no primeiro domingo de novembro (dia 04) às 00:00:00

Horário de verão termina no terceiro domingo de fevereiro (dia 17) às 00:00:00

Para suportar estas alterações de horário de verão, a Microsoft disponibilizou desde abril de 2018 as atualizações para as versões de sistemas operacionais suportadas.

Segue abaixo o artigo oficial sobre a atualização;

#  Time zone and DST changes in Windows for Brazil, Morocco, and São Tomé and Príncipe

https://support.microsoft.com/en-us/help/4093753/time-zone-and-dst-changes-in-windows-for-brazil-morocco-and-sao-tome-a

* É possível que outras atualizações tenham substituído esta atualização. Consultar o site do Catalog para ver o último kb válido.

Como esta mudança afeta os clientes de Exchange / Office 365?
==========================================

Os clientes de correio trabalham de maneiras diferentes.

• Outlook: irá utilizar a informação de fuso horário da máquina local para ajustar as reuniões. Se o Sistema Operacional estiver devidamente atualizado, o Outlook irá mostrar as reuniões com o horário correto.

• OWA: O cliente OWA utiliza as informações de fuso horário do servidor. Isto significa que usuários do OWA necessitam que a atualização de fuso horário esteja aplicada em todos os servidores Exchange da organização.

• ActiveSync: O ajuste dos compromissos no calendário dos dispositivos móveis dependem de atualização no S.O. do próprio dispositivo.

* Os servidores do Office 365 já estão atualizados com as últimas definições de horário de verão.

Informações adicionais
==========================================

Ao criar compromissos baseados em Exchange / Office 365, a solicitação da reunião inclui informações do horário de verão do organizador da reunião, ou seja, ao criar uma solicitação de reunião de uma estação de trabalho, o Outlook vai incluir o fuso horário do organizador e informações de quando o horário de verão começa e termina. Neste caso, mesmo que você tenha uma reunião recorrente que foi criada antes de sair a atualização do horário de verão, o cliente de correio tem que ser capaz de recalcular o horário do compromisso baseado nas informações atualizadas do SO da estação de trabalho ou servidor (dependendo do cliente utilizado).

Pode acontecer em alguns casos de compromissos seguirem com a data incorreta, principalmente no período Delta (período de alteração entre a antiga data de horário de verão e a nova data – neste ano de 2018 entre 21 de outubro a 03 de novembro), como se respeitasse o horário de verão de antes da atualização. Para estes casos o melhor é avaliar os compromissos individualmente, o maior motivo para isso acontecer é alguma propriedade do compromisso estar ausente ou corrompida, que pode gerar ainda resultados distintos para o mesmo compromisso se comparados em clientes diferentes como Outlook e OWA.

Para estes casos, a recomendação é rodar a ferramenta Calendar Checking Tool for Outlook (CalCheck) no calendário afetado.

https://www.microsoft.com/en-us/download/details.aspx?id=28786

A ferramenta irá gerar um relatório no formato *.csv. Verifique se o compromisso afetado está listado no relatório. Somente compromissos com erro aparecem no relatório.

Consulte o site abaixo para ver a relação dos erros e as respectivas soluções;

https://support.microsoft.com/en-us/help/2678030/information-about-the-calendar-checking-tool-for-outlook-calcheck

Para confirmar se a atualização do horário de verão foi aplicada no Windows, você pode utilizar o comando abaixo;

Antes do KB instalado:

w32tm /tz

Time zone: Current:TIME_ZONE_ID_STANDARD Bias: 180min (UTC=LocalTime+Bias)

[Standard Name:"E. South America Standard Time" Bias:0min Date:(M:2 D:3 DoW:6)]

[Daylight Name:"E. South America Daylight Time" Bias:-60min Date:(M:10 D:3 DoW:6)]

Após KB instalado:

w32tm /tz

Time zone: Current:TIME_ZONE_ID_STANDARD Bias: 180min (UTC=LocalTime+Bias)

[Standard Name:"E. South America Standard Time" Bias:0min Date:(M:2 D:3 DoW:6)]

[Daylight Name:"E. South America Daylight Time" Bias:-60min Date:(M:11 D:1 DoW:6)]

Artigos relacionados:
==========================================

# Decreto Oficial com as datas de horário de verão:

https://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm

# Horário de verão no Brasil inicia em 04 de Novembro de 2018 (lista de KBs)

https://blogs.technet.microsoft.com/latam/2018/10/17/horario-de-verao-no-brasil-inicia-em-04-de-novembro-de-2018-lista-de-kbs/

# How time zone normalization works in Microsoft Outlook

https://support.microsoft.com/en-us/help/2642044/how-time-zone-normalization-works-in-microsoft-outlook

# Information about the Calendar Checking Tool for Outlook (CalCheck)

https://support.microsoft.com/pt-br/help/2678030/information-about-the-calendar-checking-tool-for-outlook-calcheck

Olá amigos,

Conforme solicitado por alguns, criei um site de armazenamento para os blog posts de minha autoria/co-autoria.

Endereço - https://c4iocesar.wordpress.com/blog/

No momento, irei criar os posts em ambas as plataformas (WordPress e LATAM Blog).

At,

Caio Ribeiro Cesar

Sr. Technical Advisor - Exchange & Identity Online

By: Caio Ribeiro César

Agradecimentos especiais ao time de suporte da Microsoft – Joao Nascimento, Sergio Duarte & Fabio Baleizao.

Aproveitando que irei sair de férias agora no dia 02 de Novembro, irei deixar um post de lembrança para meus amigos do suporte, consultoria e parceiros.

Alguns clientes abrem chamados com problemas para migrar mailboxes para a nuvem, com o erro abaixo:

Error: MigrationPermanentException: Mailbox size 160.96GB (165,457,177,916 bytes) exceeds target quota 100GB (107,374,182,400 bytes).

Em outras palavras, a mailbox source (OnPremises) possui uma database maior do que a quota da mailbox de destino (OnCloud). O problema pode ser simples de ser resolvido, porém o recomendado é sempre planejar antes de executar.

Vamos iniciar com o entendimento do ambiente local.

Possuir mailboxes com um quota superior a 100GB seria um best practice?

Pode depender do ambiente. O Exchange 2019 possui um warn limit de mailboxes para 2TB – o que não significa que devemos utilizá-lo desta maneira.

Existe um excelente artigo escrito  pelo time de produto sobre este tema, em que a conclusão seria entre 2.5k a 5k mensagens em cada folder e que o que importa realmente seriam os números de emails e não o tamanho em si. Com o tempo, a tecnologia se adapta e inovamos soluções – pessoalmente recomendo seguir a mesma métrica do ambiente online (100GB).

Matematicamente falando: um usuário comum pode utilizar um quota de 100GB sem problemas. Tendo uma compreensão que este usuário recebe aprox. 150 emails por dia, com aproximadamente 100KB para cada mensagem teríamos 15MB de dados por dia (5.47GB por ano). Para acomodar 100GB de dados, precisaríamos de ~18 anos (e até lá espero que o custo de disk irá diminuir e o quota aumentar). Consequentemente, os tamanhos de emails seriam maiores – seria uma discussão para outro post.

Isto significa que caso o seu usuário alcance o volume de 100GB, existe uma grande chance deste volume ser anormal ; gerado por notificações automáticas de monitoramento ou anti-virus, internal SPAM entre outros.

Possuir mailboxes com um archive quota superior a 100GB seria um best practice?

O mesmo estudo acima segue para quota de archive. A questão seria comparar a utilização. O archive deve ser utilizado para um conteúdo “antigo”, sendo este utilizado apenas pelo usuário dono da mailbox.

Conforme explicado no artigo abaixo, especificamente para Exchange Online -

O uso de journaling, regras de transporte ou regras de encaminhamento automático para copiar mensagens para uma caixa de correio do Exchange Online com a finalidade de arquivamento não é permitido. A caixa de correio de arquivo morto de um usuário destina-se somente a esse usuário. A Microsoft reserva o direito de negar o arquivamento ilimitado em situações onde a caixa de correio de arquivo morto do usuário é usada para armazenar dados de arquivo morto de outros usuários.

https://docs.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits

Logicamente, para ambientes OnPremises, o quota é customizado pelo administrador que pode optar pelo valor. Seguindo a regra anterior, seria uma boa idéia possuir 50GB de quota para archive (+9 anos de conteúdo).

Para coletar informações de sizing, basta executar os comandos:

Get-MailboxStatistics mailbox | ft DisplayName, TotalItemSize, ItemCount 
Get-MailboxStatistics -archive mailbox | ft DisplayName, TotalItemSize, ItemCount

O que acontece na migração?

Uma mailbox com utilização maior que a quota de serviços do Exchange Online irá falhar na migração, com o erro de “size exceeds target quota”. Isto serve também para a utilização de quota de Recoverable Items e para procedimentos de MailboxRestoreRequest (target mailbox vs. source mailbox size & quota).

A quota de Recoverable Items é “separada” da quota da mailbox. Ela é utilizada não apenas por conteúdo recoverable como por exemplo, conteúdo de mailbox audit:

Caso o administrador precise aumentar esta quota no ambiente de Exchange Online, disponibilizamos um artigo que explica passo a passo como efetuar esta tarefa.

Como migrar uma mailbox com utilização superior a 100GB?

• Limpeza. Mitigar problemas de tecnologia também significa entender que “technology is not a panacea”. Ações de sysadmin consistem em ensinar usuários como gerenciar os dados de suas mailboxes – criando rules ou tags para remover conteúdo não utilizado.
• Caso esta mailbox não possua Archive, a recomendação seria habilitar a funcionalidade do ambiente OnPremises e mover items antigos para o Archive antes da migração. Posteriormente, basta migrar a mailbox + archive.
• Caso esta mailbox possua archive já com uma utilização próxima ou superior a 50GB, a recomendação seria:

1. Separar o archive mais “antigo” e aguardar a migração completar para dados da mailbox e do initial archive de 50GB.
2. Iniciar a migração de dados de archive remanescentes assim que o auto-expand archive habilite auxiliary archives para a mailbox da nuvem (lembrando que esta tarefa pode demorar diversos dias). Lembrando também que o auto-expand deve estar habilitado para a Mailbox Online.

Dos criadores de:

Não perca a nova moda, já disponível nas lojas:

By: Caio Ribeiro Cesar

In this post, I will be discussing some practices used by attackers in order to get authentication information for VIP users.

This is a common practice called "spear phishing", or individual phishing - first, attackers get to know the victim (usually a CISO/CTO or someone that holds important data). Then, they start the attack.

These methodologies are evolving. Spear phishing are usually mixed with social engineering in order to create a relationship between the attacker and the victim - as getting a call about the email being sent with important information available on a link that they need to click. When this email is delivered, the victim usually trusts the attacker and does not hesitate to access the information.

Let's first understand how a phishing attack is done, so we can discuss individual attacks.

1) We need a website. Maybe a copy of a reliable site, as a methodology for people to trust the information they see. Attackers add the site to the email body (or maybe a site, forum or anywhere people can click and be lurked to the attacker)

Attackers create a clone of reliable websites, or they create their own. Spear phishing usually relies on cloning as they are more precise on a single attack rather than expecting "some hits" from a 10k/100k mail list.

The example below is a clone of the old O365 portal, created by me back in 2015 (https://c4iocesar.wordpress.com/2015/08/24/exchange-online-protection-spear-phishing-attack-asf-e-safe-links/).

The attacker would simply create a DNS entry for the external IP address of this website. The webpage is identical to the old "login.microsoftonline.com".

After the website is cloned and published, the attacker will build a nice written email with this information. It's important to understand that they usually use spoofs, so these emails are sent similar to the original sender - and this is why we should use features such as SPF/Dkim/DMARC.

In the simulation below, I'm adding my webserver to the email, spoofing the sender so they can be tricked by opening and clicking on my email:

*As much as I can create a valid clone, published externally and add a real spoof in the attack, I want to keep my Kali Linux Lab in Azure. If you are a Pentester, please let the azure team know in the procedure of creating the VM.

The victim then would access the URL from my email, and the HTTP POST would be added to my webserver DB.

How can administrators prevent end users from clicking on these emails?

Exchange Online Protection has not only tools that can prevent these emails from arriving, but also features that can prevent end users from accessing the information.

1) ASF

Advanced SPAM Filter acts on the SPAM Filter for ExO. It acts by reading the email body and preventing these emails from reaching the /Inbox. For example:

This was added as a Spam Confidence Level of 6, due to the "Numeric IP in URL" action. This methodology is commonly used by attackers in order to trick users by clicking on a fake URL.

- ATP (Safe Links)

Advanced Threat Protection has become common for larger enterprises. This avoids users from reaching out to unsafe links. When the end user tries to reach out the URL, it's validated by a MS server so we are sure this URL is valid/does not contain a malware, redirect or being used as a phishing endpoint. The end user is alerted and these actions can be monitored by the company admin:

As we can see below, when the website is redirected to a phishing endpoint, we are first routed to ".safelinks.protection.outlook.com":

Information received by the end user (language can be customized):

Admin reporting for the ATP:

++++++++++++++++++++++++++++++++++++++++++++++

This is a post translation for the 2015 article written in Portuguese. Today, ATP has evolved, together with multiple Microsoft (and third party) technologies. For Microsoft, I indicate going through the CISO workshop [https://docs.microsoft.com/en-us/office365/securitycompliance/ciso-workshop
], together with the Cybersecurity Reference Architecture (MCRA) for integrated solutions.

Other solutions that can help you and your organization to be ready for these attacks:

1) SecureScore can help you (as the admin) to understand your security score for O365.

2) Phishing Simulations (phishing campaigns) are available in O365. This can help to prepare your organization culture.