Am totally unaware about this area, how Microsoft exchange server works.Just wanted to know can we integrate a exchange server using Apex Code?Is it is possible to call the exchange server from a batch/scheduled process to bring down all the emails?
For full disclosure, I have not and do not use any of the products I listed. They are listed just to give you an idea of what is available. I have no experience with them and highly recommend doing research on them before picking a solution if that is the route you wish to take.
I recommend you to consider the Agile GrinMark to Exchange Synchronizer (GESync). It provides server-side integration between Salesforce and Exchange. Integration includes two-way synchronization of Contacts, Accounts, Leads, Meetings, Calls, Tasks; Archiving emails; special scenarios to replicate and create items like Opportunities and Cases from your email client. This solution works without any client-side plugins. No need for additional configuration of standard mobile or desktop email clients (Outlook, Entourage, Mac Mail, iPhone, iPad, Android, Windows Phone, Blackberry, etc.).
If you have an MSDN/VSLC subscription, you can find the binaries there. Otherwise, it *should* be available from the eval center (although I couldn't actually find it listed there): -in/evalcenter/evaluate-office-servers
You can find the links to the available Exchange Server 2016 Cumulative Updates (which are evaluations versions by default) following this link:
-us/exchange/new-features/build-numbers-and-release-dates?view=exchserv...
I know how to send mails using outlook installed in same machine, where I'm running my code. Now, the requirement here is to access exchange server (Microsoft OWA) of my organization for sending mails in asp.net code.
You can send emails using the Exchange Web Services API (EWS). EWS is a set of old fashioned ASMX web services hosted on the same server as OWA. Microsoft has even published an open source managed API wrapper on GitHub for EWS.
You can access the Exchange 2003 mail store via HTTP using WebDAV. WebDAV is a bit of a pain to use because you may have to use Forms Based Authentication (FBA) if that is what your OWA installation requires (in comparison EWS can use Windows Authentication even if OWA on Exchange 2007/2010 is using FBA).
I have never tried sending mails using WebDAV for Exchange (although I have used WebDAV for a number of other things) but I found an example on MSDN that you may want to try. It uses Windows Authentication so it will not work if your Exchange 2003 OWA is set up to use FBA. If you need to use FBA let me know - I may have some sample code somewhere that you can use.
Understand that you will need to get the exchange administrator to give your asp.net machine access to the SMTP port (this usually Port 25) on the exchange server and set up permissions to allow you to relay messages thru the server.
Additional hunting and analysis led to the identification of several more samples along with an associated PlugX command and control (C2) infrastructure. This blog provides a technical overview of the PlugX variant discovered, indicators of compromise (IOCs) to identify it in networks and a tool developed by Unit 42 to handle payload decryption.
Palo Alto Networks customers are protected from PlugX with Cortex XDR or the Next-Generation Firewall with WildFire and Threat Prevention security subscriptions. AutoFocus users can track PlugX and PKPLUG activity using the PlugX and PKPLUG tags, respectively. Full visualization of the techniques observed and their relevant courses of action can be viewed in the Unit 42 ATOM Viewer.
The first one thousand bytes of Aro.dat (see Figure 2) indicate the file might be encrypted or possibly compressed. As it turns out, this data is nothing but random padding data likely added as a file header to evade AV signatures to thwart detection. The end of the filler data is null-terminated, which provides an identifier to the actual data entry point. Immediately following the NULL byte (0x00) is a set of x86 assembly instructions to unpack the file. In this sample, the x86 assembly starts at file offset 0x4EC with opcode 0x77. This translates to assembly mnemonic of JA (jump if above unsigned).
Figure 2 illustrates the Aro.dat file header up until the NULL byte. The data was truncated for brevity, as the bytes up until the NULL are meaningless. Red denotes the NULL byte, and green is where code execution begins.
Aro.dat is designed to remain undetected and cannot run without the aid of a specific loader. As with previous PlugX variants, code execution is achieved via a technique known as DLL side loading. Static analysis reveals that once loaded into memory, Aro.dat begins to unpack itself and initiates communication with a C2 server.
Aro.dat is, in fact, an encrypted and compressed PlugX payload. The decryption routine within Aro.dat closely resembles that of older PlugX variants (see Figure 3 below) in that it involves multiple decryption keys and bit shift operations. Once decrypted, it gets decompressed via the Windows API RtlDecompressBuffer into a Windows module (DLL). The compression algorithm is LZ compression (COMPRESSION_FORMAT_LZNT1).
The Aro.dat file contains the following string names: aross.dll, aro.exe and aro.dat. The association of these three files together provides insight into how code execution is likely achieved. VirusTotal has the following files:
This sample has the following PlugX plugins, which have an individual hardcoded date stamp, as illustrated in Table 1 below. Much has been said about these plugins in the past. In summary, they provide attackers various capabilities to monitor, update and interact with the compromised system to fulfil their objectives.
PlugX modules, such as Aro.dat, include hardcoded configuration information allowing for multiple C2 addresses. This provides fallback options for the backdoor in case some remote services are unavailable at the time of compromise. In this particular PlugX implant (SHA256: 59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F), and as shown in Figure 6 above, all four C2 configuration options reference the domain name rainydaysweb[.]com.
Overlaps between the recently discovered PlugX samples with the THOR magic bytes (the infrastructure) and other entities associated with known PKPLUG activity are highlighted in Figure 12 below, stemming from the orange rectangle and the red square, respectively.
As previously mentioned, Aro.dat (SHA256: 59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F) was downloaded from an actor-controlled GitHub repository to the target Microsoft Exchange Server using bitsadmin. As such, the specific component responsible for loading and decrypting the module is unknown. However, the connection from it to rainydaysweb[.]com is shown in the blue oval shape in Figure 12.
Examples include www.ixiaoyver[.]com and www.systeminfor[.]com that resolved in April and May 2020 respectively to 103.85.24[.]190, which acted as C2 channels for several PlugX samples (using the PLUG identifier).
With an understanding of how the encrypted payload files are constructed, Unit 42 researchers created a signature based on the x86 assembly instructions. These instructions are used to unpack the payload. (See Table 2 for a list of files discovered.)
During our research, we discovered other PlugX-encrypted payloads that have a different encoding scheme and file header. These samples are XOR encoded with the decryption key consisting of the bytes starting at file offset zero, up until the NULL byte. Typically, the key is 10 bytes in length. Once decrypted, the sample is that of a PE file (DLL). (Reference Table 3 for a list of files uncovered that follow this format.)
Unit 42 created a Python script that can decrypt and unpack encrypted PlugX payloads without having the associated PlugX loaders. It attempts to detect the type of PlugX-encrypted samples and then outputs the following:
Palo Alto Networks customers are protected from PlugX with Cortex XDR or the Next-Generation Firewall with WildFire and Threat Prevention security subscriptions. AutoFocus users can track PlugX and PKPLUG activity using the PlugX and PKPLUG tags, respectively.
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and systematically disrupt malicious cyber actors. Visit the Cyber Threat Alliance for more information
Other PlugX (PLUG magic bytes):
web.flashplayerup[.]com
downloads.flashplayerup[.]com
help.flashplayerup[.]com
index.flashplayerup[.]com
www.destroy2013[.]com
www.fitehook[.]com
www.manager2013[.]com
www.mmfhlele[.]com
detail.misecure[.]com
www.quochoice[.]com
www.systeminfor[.]com
www.emicrosoftinterview[.]com
down.emicrosoftinterview[.]com
news.petalossccaf[.]com
www.msdntoolkit[.]com
www.apple-net[.]com
hdviet.tv-vn[.]com
103.56.53[.]106
185.239.226[.]65
103.192.226[.]100
45.248.87[.]140
45.142.166[.]112
103.107.104[.]38
42.99.117[.]92
45.251.240[.]55
103.56.53[.]46
154.223.150[.]105
45.248.87[.]162
103.200.97[.]150
42.99.117[.]95
43.254.217[.]165
45.248.87[.]217